|
|
|
Has join
|
|||
|---|---|---|---|
|
#18+
имеем: Код: sql 1. 2. 3. 4. 5. Пытаюсь выполнить: Код: sql 1. 2. Где я туплю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 17:45 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey Sribnyak, Это только в 9.6 будет же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 18:02 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Ок, поставил 9.6 авторtpcc=# select version(); version --------------------------------------------------------------------------------------------------------- PostgreSQL 9.6devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4, 64-bit (1 row) подскажите, как мне добится заветного Partial Seq Scan ? делаю: авторtpcc=# set max_parallel_degree = 1; SET Time: 0.395 ms tpcc=# tpcc=# tpcc=# explain SELECT ol_number ,sum(ol_quantity) AS sum_qty ,sum(ol_amount) AS sum_amount ,avg(ol_quantity) AS avg_qty ,avg(ol_amount) AS avg_amount ,count(*) AS count_order FROM dbo.order_line WHERE ol_delivery_d > '20151006' GROUP BY ol_number ORDER BY ol_number; QUERY PLAN -------------------------------------------------------------------------------------------- Sort (cost=5443989.89..5443989.93 rows=15 width=10) Sort Key: ol_number -> HashAggregate (cost=5443989.33..5443989.60 rows=15 width=10) Group Key: ol_number -> Seq Scan on order_line (cost=0.00..3284336.60 rows=143976849 width=10) Filter: (ol_delivery_d > '2015-10-06 00:00:00'::timestamp without time zone) (6 rows) Time: 1.026 ms авторtpcc=# SELECT ol_number ,sum(ol_quantity) AS sum_qty ,sum(ol_amount) AS sum_amount ,avg(ol_quantity) AS avg_qty ,avg(ol_amount) AS avg_amount ,count(*) AS count_order FROM dbo.order_line WHERE ol_delivery_d > '20151006' GROUP BY ol_number ORDER BY ol_number; ... Time: 62600.480 ms И то же при возможно параллельном выолнении: авторtpcc=# set max_parallel_degree = 32; SET Time: 0.389 ms tpcc=# tpcc=# tpcc=# explain SELECT ol_number ,sum(ol_quantity) AS sum_qty ,sum(ol_amount) AS sum_amount ,avg(ol_quantity) AS avg_qty ,avg(ol_amount) AS avg_amount ,count(*) AS count_order FROM dbo.order_line WHERE ol_delivery_d > '20151006' GROUP BY ol_number ORDER BY ol_number; QUERY PLAN -------------------------------------------------------------------------------------------- Sort (cost=5443989.89..5443989.93 rows=15 width=10) Sort Key: ol_number -> HashAggregate (cost=5443989.33..5443989.60 rows=15 width=10) Group Key: ol_number -> Seq Scan on order_line (cost=0.00..3284336.60 rows=143976849 width=10) Filter: (ol_delivery_d > '2015-10-06 00:00:00'::timestamp without time zone) (6 rows) автор tpcc=# SELECT ol_number ,sum(ol_quantity) AS sum_qty ,sum(ol_amount) AS sum_amount ,avg(ol_quantity) AS avg_qty ,avg(ol_amount) AS avg_amount ,count(*) AS count_order FROM dbo.order_line WHERE ol_delivery_d > '20151006' GROUP BY ol_number ORDER BY ol_number; ol_number | sum_qty | sum_amount | avg_qty | avg_amount | count_order -----------+----------+------------------+--------------------+-----------------------+------------- 1 | 72000000 | 72001066703.2736 | 5.0000000000000000 | 5000.0740766162222222 | 14400000 2 | 72000000 | 71979552805.7618 | 5.0000000000000000 | 4998.5800559556805556 | 14400000 3 | 72000000 | 72016792814.8090 | 5.0000000000000000 | 5001.1661676950694444 | 14400000 4 | 72000000 | 72026174580.4301 | 5.0000000000000000 | 5001.8176791965347222 | 14400000 5 | 72000000 | 71995979084.4438 | 5.0000000000000000 | 4999.7207697530416667 | 14400000 6 | 65453315 | 65445858569.8675 | 5.0000000000000000 | 4999.4304008794283376 | 13090663 7 | 58910155 | 58882197836.0727 | 5.0000000000000000 | 4997.6271354295961367 | 11782031 8 | 52362530 | 52367429545.1200 | 5.0000000000000000 | 5000.4678483946440327 | 10472506 9 | 45822420 | 45821006829.0195 | 5.0000000000000000 | 4999.8457991764184432 | 9164484 10 | 39274160 | 39261904262.5124 | 5.0000000000000000 | 4998.4397199726741450 | 7854832 11 | 32723110 | 32713101576.5575 | 5.0000000000000000 | 4998.4707407941207300 | 6544622 12 | 26165965 | 26175605528.6040 | 5.0000000000000000 | 5001.8421886225101960 | 5233193 13 | 19619965 | 19618861642.7164 | 5.0000000000000000 | 4999.7188177237828916 | 3923993 14 | 13080865 | 13086910283.7150 | 5.0000000000000000 | 5002.3107354578615405 | 2616173 15 | 6543780 | 6544684119.6085 | 5.0000000000000000 | 5000.6908236588791188 | 1308756 (15 rows) Time: 62657.160 ms ПРи этом точно процессоры во время выполнения не задействованы: автор# mpstat -P ALL Linux 3.19.0-49-generic (DBBestUBP) 02/09/2016 _x86_64_ (32 CPU) 07:51:29 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 07:51:29 AM all 0.49 0.00 0.09 0.97 0.00 0.00 0.00 0.00 0.00 98.44 07:51:29 AM 0 0.01 0.00 0.21 0.04 0.00 0.01 0.00 0.00 0.00 99.72 07:51:29 AM 1 0.03 0.00 0.07 0.16 0.00 0.00 0.00 0.00 0.00 99.75 07:51:29 AM 2 0.00 0.00 0.05 0.07 0.00 0.00 0.00 0.00 0.00 99.87 07:51:29 AM 3 0.01 0.00 0.07 0.11 0.00 0.00 0.00 0.00 0.00 99.81 07:51:29 AM 4 0.01 0.00 0.05 0.22 0.00 0.00 0.00 0.00 0.00 99.72 07:51:29 AM 5 0.05 0.00 0.15 0.51 0.00 0.00 0.00 0.00 0.00 99.29 07:51:29 AM 6 0.02 0.00 0.02 0.07 0.00 0.00 0.00 0.00 0.00 99.88 07:51:29 AM 7 0.00 0.00 0.01 0.12 0.00 0.00 0.00 0.00 0.00 99.86 07:51:29 AM 8 0.01 0.00 0.07 0.21 0.00 0.00 0.00 0.00 0.00 99.72 07:51:29 AM 9 0.00 0.00 0.01 0.21 0.00 0.00 0.00 0.00 0.00 99.78 07:51:29 AM 10 0.01 0.00 0.01 0.11 0.00 0.00 0.00 0.00 0.00 99.87 07:51:29 AM 11 0.00 0.00 0.02 0.04 0.00 0.00 0.00 0.00 0.00 99.93 07:51:29 AM 12 0.00 0.00 0.02 0.07 0.00 0.00 0.00 0.00 0.00 99.90 07:51:29 AM 13 0.01 0.00 0.11 0.07 0.00 0.00 0.00 0.00 0.00 99.81 07:51:29 AM 14 0.01 0.00 0.02 0.04 0.00 0.00 0.00 0.00 0.00 99.92 07:51:29 AM 15 0.02 0.00 0.06 0.12 0.00 0.00 0.00 0.00 0.00 99.80 07:51:29 AM 16 0.00 0.00 0.06 0.12 0.00 0.00 0.00 0.00 0.00 99.81 07:51:29 AM 17 0.01 0.00 0.07 0.23 0.00 0.00 0.00 0.00 0.00 99.68 07:51:29 AM 18 0.01 0.00 0.04 0.30 0.00 0.00 0.00 0.00 0.00 99.65 07:51:29 AM 19 0.01 0.00 0.54 0.07 0.00 0.00 0.00 0.00 0.00 99.38 07:51:29 AM 20 0.01 0.00 0.08 8.63 0.00 0.00 0.00 0.00 0.00 91.27 07:51:29 AM 21 0.03 0.00 0.07 5.34 0.00 0.00 0.00 0.00 0.00 94.56 07:51:29 AM 22 0.01 0.00 0.09 0.41 0.00 0.00 0.00 0.00 0.00 99.49 07:51:29 AM 23 0.01 0.00 0.05 0.19 0.00 0.00 0.00 0.00 0.00 99.75 07:51:29 AM 24 15.27 0.00 0.62 12.46 0.00 0.02 0.00 0.00 0.00 71.62 07:51:29 AM 25 0.02 0.00 0.12 0.29 0.00 0.00 0.00 0.00 0.00 99.57 07:51:29 AM 26 0.03 0.00 0.03 0.14 0.00 0.00 0.00 0.00 0.00 99.79 07:51:29 AM 27 0.00 0.00 0.01 0.06 0.00 0.00 0.00 0.00 0.00 99.93 07:51:29 AM 28 0.01 0.00 0.01 0.18 0.00 0.00 0.00 0.00 0.00 99.79 07:51:29 AM 29 0.00 0.00 0.08 0.13 0.00 0.00 0.00 0.00 0.00 99.78 07:51:29 AM 30 0.01 0.00 0.01 0.31 0.00 0.00 0.00 0.00 0.00 99.67 07:51:29 AM 31 0.08 0.00 0.03 0.04 0.00 0.00 0.00 0.00 0.00 99.84 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 10:57 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey Sribnyak, Надеюсь вы понимаете, что 9.6 ещё далёк от стабилизации и даже от завершения. Будет ещё 1 commitfest в марте, после которого заморозка кода. Бета может появиться только в июне. Оно сырое. И да, параллельные агрегаты ещё не были закомичены — в работе, один из последних патчей для 9.6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 11:42 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
vyegorov, Это лишь тестовая среда для оценки производительности. Стандартный тест tpcc На очень больших данных. ПРи этом сравнение на одном и том же железе и одних и тех же данных но в разных серверах баз данных. Была очень большая надежда на этот функционал. Т.к иначе результаты у Postgresql не очень хорошие. Я бы сказал плохие. например запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Не выполняется в принципе за разумное время (отбил через несколько часов.) план при этом такой: автор QUERY PLAN -------------------------------------------------------------------------------------------------------------- Sort (cost=690614487.95..690614488.15 rows=80 width=57) Sort Key: supplier.su_name -> Hash Join (cost=690614482.64..690614485.42 rows=80 width=57) Hash Cond: ((((stock.s_i_id * stock.s_w_id) % 10000)) = supplier.su_suppkey) -> HashAggregate (cost=690614060.73..690614062.73 rows=200 width=4) Group Key: ((stock.s_i_id * stock.s_w_id) % 10000) -> HashAggregate (cost=690458060.73..690554060.73 rows=4800000 width=12) Group Key: stock.s_i_id, stock.s_w_id, stock.s_quantity Filter: ((650 * stock.s_quantity) > sum(order_line.ol_quantity)) -> Hash Join (cost=3312648.69..391900548.77 rows=29855751196 width=12) Hash Cond: (order_line.ol_i_id = item.i_id) -> Seq Scan on order_line (cost=0.00..3284336.60 rows=143976849 width=6) Filter: (ol_delivery_d > '2015-10-08 00:00:00'::timestamp without time zone) -> Hash (cost=3052926.69..3052926.69 rows=20777760 width=14) -> Hash Join (cost=3330.09..3052926.69 rows=20777760 width=14) Hash Cond: (stock.s_i_id = item.i_id) -> Seq Scan on stock (cost=0.00..2661819.00 rows=48000000 width=10) -> Hash (cost=2789.00..2789.00 rows=43287 width=4) -> Seq Scan on item (cost=0.00..2789.00 rows=43287 width=4) Filter: (i_data ~~ '%%4%%'::text) -> Hash (cost=419.90..419.90 rows=161 width=61) -> Hash Join (cost=2.79..419.90 rows=161 width=61) Hash Cond: (supplier.su_nationkey = nation.n_nationkey) -> Seq Scan on supplier (cost=0.00..378.00 rows=10000 width=65) -> Hash (cost=2.77..2.77 rows=1 width=4) -> Seq Scan on nation (cost=0.00..2.77 rows=1 width=4) Filter: (n_name ~~ '%Germany%'::text) Я конечно понимаю, что я не умею готовить Postgresql. Но, сильно не понимаю, что я делаю не так... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 12:01 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
при этом в на других серверах, к примеру, HANA, MS SQL, DB2 этот же запрос выполняется пару секунд, на этих же данных и на этом железе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 12:07 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey Sribnyak, 1. Используйте `EXPLAIN (analyze, buffers)` 2. Оберните вывод тагом `[src]` — читать неудобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 13:09 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey Sribnyakvyegorov, Это лишь тестовая среда для оценки производительности. Стандартный тест tpcc На очень больших данных. ПРи этом сравнение на одном и том же железе и одних и тех же данных но в разных серверах баз данных. Была очень большая надежда на этот функционал. Т.к иначе результаты у Postgresql не очень хорошие. Я бы сказал плохие. ... Я конечно понимаю, что я не умею готовить Postgresql. Но, сильно не понимаю, что я делаю не так... Я бы предположил несколько вариантов: 1)work_men не под tpcc (там гигабай work_mem под такие запросы самое то) 2)мало shared_buffers 3)низкий default_statistics_target и в итоге план неудачный 4)непрогретый кеш базы перед началом теста а база не на ssd а на механике 5)какие то индексы есть на других базах и почему то нет в tpcc реализации на postgresql (как минимум сравнить наличие индекса по ol_delivery_d) 6)не сделан analyze после загрузки данных в базу -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 13:31 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey Sribnyak, а сделать индекс на dbo.stock типа Код: sql 1. 2. и попробовать можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 13:39 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
LonepsychoAndrey Sribnyak, а сделать индекс на dbo.stock типа Код: sql 1. 2. и попробовать можно? индексм создал: но в плане я не вижу, что он должен участвовать... попробую запустить сейчас Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 14:05 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk Я бы предположил несколько вариантов: 1)work_men не под tpcc (там гигабай work_mem под такие запросы самое то) Код: sql 1. 2. 3. 4. 2)мало shared_buffers Код: sql 1. 2. 3. 3)низкий default_statistics_target и в итоге план неудачный Код: sql 1. 2. 4)непрогретый кеш базы перед началом теста а база не на ssd а на механике Сам Postgress и linux на ssd База на 10 рейде из 4 дисков Журнал транзакций на зеркале из 2 дисков 5)какие то индексы есть на других базах и почему то нет в tpcc реализации на postgresql (как минимум сравнить наличие индекса по ol_delivery_d) Ну например SQL server, тот же запрос... и план выполнения... кроме кластерных индексов - нет никаких Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. Выполняется - за секунду 6)не сделан analyze после загрузки данных в базу НУ число записей в планах актуальное -- Maxim Boguk www.postgresql-consulting.ru [/quot] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 14:18 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey Sribnyak Код: sql 1. 1. Пожалуйста `EXPLAIN (analyze, buffers) SELECT ...`. 2. Параллельной аггрегации пока нет, так что приблизится к MS SQL не выйдет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 14:22 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
vyegorovAndrey Sribnyak Код: sql 1. 1. Пожалуйста `EXPLAIN (analyze, buffers) SELECT ...`. Не выполняется, висит столко же , сколько и обычное выполнение я пытался - отбил через час... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 14:31 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
vyegorovAndrey Sribnyak Код: sql 1. 2. Параллельной аггрегации пока нет, так что приблизится к MS SQL не выйдет. Я уже согласен, если он выполнится за вменяемое время вообще... (меньше часа желательно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 14:34 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey SribnyakLonepsychoAndrey Sribnyak, а сделать индекс на dbo.stock типа Код: sql 1. 2. и попробовать можно? индексм создал: но в плане я не вижу, что он должен участвовать... попробую запустить сейчас Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. Можно ли выполнить Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. или он тоже зависает надолго? Если зависает то что говорит Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. и что говорит Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ? PS: у меня есть подозрение что другие базы выполняют этот подзапрос следующим методом (ну или похожим) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. таким образом избегая безумного по обьему результата обьединения таблиц dbo.order_line и dbo.item по ol_i_id = s_i_id -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 14:43 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey Sribnyak, Ясно как оно делает... это я не угадал слегка... mssql делает вот что: explain analyze WITH ol AS ( SELECT sum(ol_quantity) as sum_ol_quantity, ol_i_id FROM dbo.order_line WHERE ol_delivery_d > '20151008' AND EXISTS (SELECT * FROM dbo.item WHERE i_id = ol_i_id AND i_data LIKE '%%4%%') GROUP BY ol_i_id ) SELECT ((s_i_id * s_w_id) % 10000) FROM dbo.stock WHERE EXISTS (SELECT * FROM ol WHERE ol_i_id = s_i_id AND 650*s_quantity > sum_ol_quantity); В принципе это корректная замена но предпросчет частичных аггрегатов не поддерживается postgresql оптимизатором. Тут запрос надо переписывать под pg. Ключевое тут - сначала подсчитать суммы итемов в dbo.order_line а потом уже начинать соединять результат с dbo.stock. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 15:04 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Последний - смог выполнить: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. Первых два, все еще висят ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 15:19 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Maxim BogukAndrey Sribnyak, Ясно как оно делает... это я не угадал слегка... mssql делает вот что: explain analyze WITH ol AS ( SELECT sum(ol_quantity) as sum_ol_quantity, ol_i_id FROM dbo.order_line WHERE ol_delivery_d > '20151008' AND EXISTS (SELECT * FROM dbo.item WHERE i_id = ol_i_id AND i_data LIKE '%%4%%') GROUP BY ol_i_id ) SELECT ((s_i_id * s_w_id) % 10000) FROM dbo.stock WHERE EXISTS (SELECT * FROM ol WHERE ol_i_id = s_i_id AND 650*s_quantity > sum_ol_quantity); В принципе это корректная замена но предпросчет частичных аггрегатов не поддерживается postgresql оптимизатором. Тут запрос надо переписывать под pg. Ключевое тут - сначала подсчитать суммы итемов в dbo.order_line а потом уже начинать соединять результат с dbo.stock. -- Maxim Boguk www.postgresql-consulting.ru Да, так получше, спасибо: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 15:26 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
Andrey Sribnyak, А так лучше не станет? Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 15:39 |
|
||
|
Has join
|
|||
|---|---|---|---|
|
#18+
vyegorovAndrey Sribnyak, А так лучше не станет? Код: sql 1. 2. Там, как минимум у таблицу Order_line есть используемое поле ol_quantity я даже пытался "читить таким образом" создал фильтрованный индекс по дате, и посмотрел, что выйдет: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. И только, если явным образом запретить: Код: sql 1. то этот индекс, вроде как начинает использоваться... но ни к чему хорошему это не приводит... Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2016, 16:07 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39166435&tid=1997451]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
174ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 468ms |

| 0 / 0 |
