|
|
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
Доброе время суток. Есть 2 таблицы CREATE TABLE part.indexed_result_0 ( -- Унаследована from table indexed_result: id bigint NOT NULL DEFAULT nextval('indexed_result__id_seq'::regclass), -- Унаследована from table indexed_result: id_article bigint, -- Унаследована from table indexed_result: key_in_spr bigint, CONSTRAINT pk_indexed_result_17 PRIMARY KEY (id), CONSTRAINT indexed_result_17_id_article_check CHECK (id_article >= (17 * 100000) AND id_article < ((17 + 1) * 100000)) ) INHERITS (indexed_result); CREATE INDEX idx_indexed_result_17_id_article ON part.indexed_result_17 USING btree (id_article); CREATE TABLE spr_article ( id bigint NOT NULL, name text, is_check boolean DEFAULT false, CONSTRAINT pk_spr_article_ PRIMARY KEY (id) ) indexed_result ~10 млн.записей , spr_article_old ~ 2 млн.записей. indexed_result разбит на партиции по признаку id_article (по ~ 0.5 млн. записей в таблице). Есть запрос Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Планировщик отказывается от использования индекса, выдавая следующий результат "Hash Join (cost=250594.40..698734.05 rows=9215951 width=32)" " Hash Cond: (ir.id_article = sa.id)" " -> Append (cost=0.00..168969.50 rows=9215951 width=24)" " -> Seq Scan on indexed_result ir (cost=0.00..0.00 rows=1 width=24)" " -> Seq Scan on indexed_result_0 ir (cost=0.00..5569.76 rows=303776 width=24)" " -> Seq Scan on indexed_result_1 ir (cost=0.00..5404.77 rows=294777 width=24)" " -> Seq Scan on indexed_result_10 ir (cost=0.00..8606.15 rows=469415 width=24)" " -> Seq Scan on indexed_result_11 ir (cost=0.00..8764.31 rows=478031 width=24)" " -> Seq Scan on indexed_result_12 ir (cost=0.00..8214.69 rows=448069 width=24)" " -> Seq Scan on indexed_result_13 ir (cost=0.00..9048.07 rows=493507 width=24)" " -> Seq Scan on indexed_result_14 ir (cost=0.00..8859.08 rows=483208 width=24)" " -> Seq Scan on indexed_result_15 ir (cost=0.00..9212.89 rows=502489 width=24)" " -> Seq Scan on indexed_result_16 ir (cost=0.00..9004.21 rows=491121 width=24)" " -> Seq Scan on indexed_result_17 ir (cost=0.00..8651.94 rows=471894 width=24)" " -> Seq Scan on indexed_result_18 ir (cost=0.00..9210.47 rows=502347 width=24)" " -> Seq Scan on indexed_result_19 ir (cost=0.00..9215.08 rows=502608 width=24)" " -> Seq Scan on indexed_result_2 ir (cost=0.00..6957.68 rows=379468 width=24)" " -> Seq Scan on indexed_result_20 ir (cost=0.00..8174.59 rows=445859 width=24)" " -> Seq Scan on indexed_result_3 ir (cost=0.00..6537.63 rows=356563 width=24)" " -> Seq Scan on indexed_result_4 ir (cost=0.00..6718.68 rows=366468 width=24)" " -> Seq Scan on indexed_result_5 ir (cost=0.00..6002.80 rows=327380 width=24)" " -> Seq Scan on indexed_result_6 ir (cost=0.00..8276.27 rows=451427 width=24)" " -> Seq Scan on indexed_result_7 ir (cost=0.00..9236.98 rows=503798 width=24)" " -> Seq Scan on indexed_result_8 ir (cost=0.00..8548.10 rows=466210 width=24)" " -> Seq Scan on indexed_result_9 ir (cost=0.00..8755.35 rows=477535 width=24)" " -> Hash (cost=215383.18..215383.18 rows=2025618 width=16)" " -> Seq Scan on spr_article_old sa (cost=0.00..215383.18 rows=2025618 width=16)" При насильном использовании индекса результат еще более удручающий (set enable_seqscan = false;) "Merge Join (cost=10000000000.50..10043144012.98 rows=9215951 width=32)" " Merge Cond: (sa.id = ir.id_article)" " -> Index Scan using pk_spr_article on spr_article_old sa (cost=0.00..7678088.74 rows=2025618 width=16)" " -> Materialize (cost=10000000000.50..10035345660.81 rows=9215951 width=24)" " -> Merge Append (cost=10000000000.50..10035322620.93 rows=9215951 width=24)" " Sort Key: ir.id_article" " -> Sort (cost=10000000000.01..10000000000.01 rows=1 width=24)" " Sort Key: ir.id_article" " -> Seq Scan on indexed_result ir (cost=10000000000.00..10000000000.00 rows=1 width=24)" " -> Index Scan using idx_indexed_result_0_id_article on indexed_result_0 ir (cost=0.00..1149596.92 rows=303776 width=24)" " -> Index Scan using idx_indexed_result_1_id_article on indexed_result_1 ir (cost=0.00..1115769.94 rows=294777 width=24)" " -> Index Scan using idx_indexed_result_10_id_article on indexed_result_10 ir (cost=0.00..1777097.53 rows=469415 width=24)" " -> Index Scan using idx_indexed_result_11_id_article on indexed_result_11 ir (cost=0.00..1809874.77 rows=478031 width=24)" " -> Index Scan using idx_indexed_result_12_id_article on indexed_result_12 ir (cost=0.00..1696437.33 rows=448069 width=24)" " -> Index Scan using idx_indexed_result_13_id_article on indexed_result_13 ir (cost=0.00..1868338.91 rows=493507 width=24)" " -> Index Scan using idx_indexed_result_14_id_article on indexed_result_14 ir (cost=0.00..1829272.42 rows=483208 width=24)" " -> Index Scan using idx_indexed_result_15_id_article on indexed_result_15 ir (cost=0.00..1902105.64 rows=502489 width=24)" " -> Index Scan using idx_indexed_result_16_id_article on indexed_result_16 ir (cost=0.00..1859207.12 rows=491121 width=24)" " -> Index Scan using idx_indexed_result_17_id_article on indexed_result_17 ir (cost=0.00..1786610.71 rows=471894 width=24)" " -> Index Scan using idx_indexed_result_18_id_article on indexed_result_18 ir (cost=0.00..1902019.51 rows=502347 width=24)" " -> Index Scan using idx_indexed_result_19_id_article on indexed_result_19 ir (cost=0.00..1902587.43 rows=502608 width=24)" " -> Index Scan using idx_indexed_result_2_id_article on indexed_result_2 ir (cost=0.00..1436584.31 rows=379468 width=24)" " -> Index Scan using idx_indexed_result_20_id_article on indexed_result_20 ir (cost=0.00..1688032.18 rows=445859 width=24)" " -> Index Scan using idx_indexed_result_3_id_article on indexed_result_3 ir (cost=0.00..1349648.73 rows=356563 width=24)" " -> Index Scan using idx_indexed_result_4_id_article on indexed_result_4 ir (cost=0.00..1387109.31 rows=366468 width=24)" " -> Index Scan using idx_indexed_result_5_id_article on indexed_result_5 ir (cost=0.00..1239362.99 rows=327380 width=24)" " -> Index Scan using idx_indexed_result_6_id_article on indexed_result_6 ir (cost=0.00..1708995.70 rows=451427 width=24)" " -> Index Scan using idx_indexed_result_7_id_article on indexed_result_7 ir (cost=0.00..1907377.28 rows=503798 width=24)" " -> Index Scan using idx_indexed_result_8_id_article on indexed_result_8 ir (cost=0.00..1764693.45 rows=466210 width=24)" " -> Index Scan using idx_indexed_result_9_id_article on indexed_result_9 ir (cost=0.00..1807879.33 rows=477535 width=24)" Вопрос - как заставить Postgres использовать индексы и делать это достаточно эффективно? Размеры индексов таковы, что они все целиком влезают в shared_buffer ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 14:49 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakamaВопрос - как заставить Postgres использовать индексы стесняюсь спросить - а на.для.зачем ? kamakama... и делать это достаточно эффективно? Размеры индексов таковы, что они все целиком влезают в shared_buffer -- в данном случае никак -- все рано ему за каждой запись-пись потом на диск лазать. Дешевле прочитать все одним куском, как он и делает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 15:04 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakama, Кстати, что Вы собираетесь делать с 9 млн. записей на клиенте? Что будет, если вовсе отказаться от разбиения на партиции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 15:21 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
/\/\/\/\/\/\, Нет, это не для клиента, это один из подзапросов более большого запроса, выполняемого на стороне сервера. Сам большой запрос генерируется полуавтоматически, поэтому возможностей по его модификации немного. Конечный результат - не более 100 строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 15:26 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakama, Ога. Таким образом, 9 млн строк где-то сохраняются в недрах сервера, затем фильтруются и выводится результат в 100 строк. Сохранение явно идет на диск, затем там же на диске идет сортировка и отбор всего этого так же явно по диску. А Вы беспокоитесь о каких-то индексах. Стоит ли беспокоиться о том, что не можете изменить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 15:38 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
Меня больше интересует другое. Почему оптимизатор снача склеивает все части партиции, а потом накладывает ограничение? Почему он не применяет их последовательно к каждой части партиции и не склеивает полученые результаты? Вообще, у меня сложилось впечатление, что в части работы с партициями оптимизатор не очень хороший. В частности, идентичные по смыслу и результату запросы выполняются совершенно по разному Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Выдает "Hash Join (cost=248616.40..283555.92 rows=316157 width=24)" " Hash Cond: (ir.id_article = spr_article_old.id)" " -> Append (cost=0.00..17787.76 rows=316157 width=24)" " -> Seq Scan on indexed_result ir (cost=0.00..0.00 rows=1 width=24)" " Filter: (id_article > 1900000)" " -> Bitmap Heap Scan on indexed_result_19 ir (cost=3142.71..9425.91 rows=167536 width=24)" " Recheck Cond: (id_article > 1900000)" " -> Bitmap Index Scan on idx_indexed_result_19_id_article (cost=0.00..3100.83 rows=167536 width=0)" " Index Cond: (id_article > 1900000)" " -> Bitmap Heap Scan on indexed_result_20 ir (cost=2788.10..8361.85 rows=148620 width=24)" " Recheck Cond: (id_article > 1900000)" " -> Bitmap Index Scan on idx_indexed_result_20_id_article (cost=0.00..2750.95 rows=148620 width=0)" " Index Cond: (id_article > 1900000)" " -> Hash (cost=215383.18..215383.18 rows=2025618 width=8)" " -> Seq Scan on spr_article_old (cost=0.00..215383.18 rows=2025618 width=8)" А логически идентичное Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. "Hash Join (cost=227290.47..618257.38 rows=3071984 width=24)" " Hash Cond: (ir.id_article = spr_article_old.id)" " -> Append (cost=0.00..168969.50 rows=9215951 width=24)" " -> Seq Scan on indexed_result ir (cost=0.00..0.00 rows=1 width=24)" " -> Seq Scan on indexed_result_0 ir (cost=0.00..5569.76 rows=303776 width=24)" " -> Seq Scan on indexed_result_1 ir (cost=0.00..5404.77 rows=294777 width=24)" " -> Seq Scan on indexed_result_10 ir (cost=0.00..8606.15 rows=469415 width=24)" " -> Seq Scan on indexed_result_11 ir (cost=0.00..8764.31 rows=478031 width=24)" " -> Seq Scan on indexed_result_12 ir (cost=0.00..8214.69 rows=448069 width=24)" " -> Seq Scan on indexed_result_13 ir (cost=0.00..9048.07 rows=493507 width=24)" " -> Seq Scan on indexed_result_14 ir (cost=0.00..8859.08 rows=483208 width=24)" " -> Seq Scan on indexed_result_15 ir (cost=0.00..9212.89 rows=502489 width=24)" " -> Seq Scan on indexed_result_16 ir (cost=0.00..9004.21 rows=491121 width=24)" " -> Seq Scan on indexed_result_17 ir (cost=0.00..8651.94 rows=471894 width=24)" " -> Seq Scan on indexed_result_18 ir (cost=0.00..9210.47 rows=502347 width=24)" " -> Seq Scan on indexed_result_19 ir (cost=0.00..9215.08 rows=502608 width=24)" " -> Seq Scan on indexed_result_2 ir (cost=0.00..6957.68 rows=379468 width=24)" " -> Seq Scan on indexed_result_20 ir (cost=0.00..8174.59 rows=445859 width=24)" " -> Seq Scan on indexed_result_3 ir (cost=0.00..6537.63 rows=356563 width=24)" " -> Seq Scan on indexed_result_4 ir (cost=0.00..6718.68 rows=366468 width=24)" " -> Seq Scan on indexed_result_5 ir (cost=0.00..6002.80 rows=327380 width=24)" " -> Seq Scan on indexed_result_6 ir (cost=0.00..8276.27 rows=451427 width=24)" " -> Seq Scan on indexed_result_7 ir (cost=0.00..9236.98 rows=503798 width=24)" " -> Seq Scan on indexed_result_8 ir (cost=0.00..8548.10 rows=466210 width=24)" " -> Seq Scan on indexed_result_9 ir (cost=0.00..8755.35 rows=477535 width=24)" " -> Hash (cost=216212.39..216212.39 rows=675206 width=8)" " -> Bitmap Heap Scan on spr_article_old (cost=12645.32..216212.39 rows=675206 width=8)" " Recheck Cond: (id > 1900000)" " -> Bitmap Index Scan on pk_spr_article (cost=0.00..12476.52 rows=675206 width=0)" " Index Cond: (id > 1900000)" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 15:45 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakama/\/\/\/\/\/\, Нет, это не для клиента, это один из подзапросов более большого запроса, выполняемого на стороне сервера. Сам большой запрос генерируется полуавтоматически, поэтому возможностей по его модификации немного. Конечный результат - не более 100 строк. вам надо или руками инжектировать сюда те фильтры, которые оставляют в итоге "не более 100 строк" или оставить возможность серверу спланировать перенос условий сюда (т.е. не совать запрос в CTE) и в том и в другом случае вопрос об оптимизации запроса на 9 лямов записей не стоит. а то, что нужно/можно оптимизировать, -- мы не увидели. в общем то всё искусство писания запросов в том и состоит -- дать планеру как можно раньше эффективно отфильтровать наборы, которые (уже маленькие) потом можно вертеть очень неоптимально -- это уже не важно. Т.е. вы конечно имеете дело с множествами и декларациями. Но в реализации -- не декларации, а алгоритмы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 15:48 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
/\/\/\/\/\/\, Вообще да, можно поэкспериментировать с настройками postgresql.conf. Типа work_mem. Но по хорошему - почему это все добро не кладется в shared_buffer? места там завались - 16 GB ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 15:50 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
интересуюсь, Это то понятно, что чем больше отсечешь в начале, тем меньше промежуточные объемы и быстрее результат. Возможностей для этого мало - автогенерация кода увы не дает простора для творчества, точнее, его очень мало ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 15:53 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakamaинтересуюсь, Это то понятно, что чем больше отсечешь в начале, тем меньше промежуточные объемы и быстрее результат. Возможностей для этого мало - автогенерация кода увы не дает простора для творчества, точнее, его очень мало вот мы и нашли корень проблемы. боритесь с автогенерацией , либо приданием ей требуемой интеллектуальности (что чуть более, чем творчество ) , или искоренением недостаточно гибкой как я понимаю -- взяли известное поделие криворуких овнокодеров (коих -- чуть более, чем все), и теперь успешно с ним боретесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 16:01 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakama, как я уже писал в другом топике сегодня у оптимизатора есть ограниченный обьем того что он делает... например из a=b and b>1000 он не будет выводить за програмиста a=b and b>1000 and a>1000 - Это дело разработчика/DBA. Есть сотни подобных моментов которые надо руками оптимизировать и вряд ли это будет исправлено (глобально) в будущем... Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c. PS: это не касается партиций вообще а просто вот природа так устроена у PostgreSQL (и не только) оптимизатора. Так как иначе процесс планирования запроса будет идти минутами что неприемлемо. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 16:10 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakama, и да, оптимайзер, с т.з. разноса условий по inner join-у в pg далеко не торт. вы сами видите -- то он одну таблу по индексу берёт, то другую. а чтобы обе -- надо оба условия писануть --- тогда всё будет чики-поки мало индусов в опенсорсе, не башляет им жадный буржуин ларри элисон такого много чего есть, не реализованного из "удобств" но механизмы (реализованные) есть [есть упорные ребята - пишут], и достучаться до них можно руками и , стало быть, автоматику сбора запросов, без учёта этих проблем ,эффективно не написать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 16:11 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
интересуюсь, Ну, не совсем овнокодеры это писали. Суть однако не меняется - как можно перестроить маленький подзапрос (как вариант - поковырять настройки postgresql.conf), чтоб бы все это хозяйство крутилось в памяти. Все таблицы в сумме занимают не более 3 GB в целом и 4 - вместе с индексами. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 16:18 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakamaинтересуюсь, Ну, не совсем овнокодеры это писали. этого не может быть, потому что не может быть никогда. любой имевший дело с линуксами или виндой это знает а кто оракл видал -- тот в цирке не смеётся ну и т.д. пишите свой генератор, прикручивайте свои фичи как вариант -- садитесь за си, исходники постгреса -- и вперде -- патчить планировщик там миллионы человеко--часов не затрачены kamakamaСуть однако не меняется - как можно перестроить маленький подзапрос (как вариант - поковырять настройки postgresql.conf), чтоб бы все это хозяйство крутилось в памяти. Все таблицы в сумме занимают не более 3 GB в целом и 4 - вместе с индексами. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. вы пишете такой подзапрос, который не нужно и даже вредно оптимизировать. пока вы этого не понимаете, вам ни генератор писать, ни сами запросы -- незачем. вам метлу надо осваивать. и в клининг менеджеры трудоустраиваться. благо - гастеры поразбежались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 16:25 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
kamakama, За это отвечает параметр work_mem ( RTFM ). К размещению 9 млн записей в памяти отношусь крайне скептически. Может быть писали опытные и аккуратные разработчики. Но цели и параметры оценки их работы явне не совпадают с Вашими. Поэтому результат немного предсказуем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 16:26 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
/\/\/\/\/\/\, Это все ясно. Я в общем то тоже. Просто сейчас пограничное состояние или пилить как есть по мелочам, или радикально менять на OLAP. Склоняюсь к последнему ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 16:42 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukkamakama, Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c. Вообще-то будет, начиная с 7.4 , страницы 8-11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 17:04 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
vyegorovMaxim Bogukkamakama, Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c. Вообще-то будет, начиная с 7.4 , страницы 8-11. Круть, а чего он тогда IS NOT NULL в соседней теме не выводит? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 17:53 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
vyegorovMaxim Bogukkamakama, Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c. Вообще-то будет, начиная с 7.4 , страницы 8-11. проверил -- вроде бы да, работает. но только если типы совпадают. но если типы не совпадают -- это было бы видно в планах для предложения фильтра. а этого тоже не видно. в случае равенства -- еще работает, в случае неравенства, как у автора, сразу вырождается в сек-скан по партициям той, по которой не указано. там недописано что-то для разных операторов, в планере. Может быть лейн ешё что-то подкрутит со временем. для непартицированной -- тоже (сек скан), если вторая -- партицирована. но индекс скан -- если вторая сингл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 18:07 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
Nitro_Junkievyegorovпропущено... Вообще-то будет, начиная с 7.4 , страницы 8-11. Круть, а чего он тогда IS NOT NULL в соседней теме не выводит? :) потому, что это другой оператор. То, что он так же позволяет перенос -- надо отдельно писать. особо доставляет то, что IS NOT DISTINCT индексами не охвачен (особо -- для сравнения компаундов индексных полей) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 18:11 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
vyegorovMaxim Bogukkamakama, Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c. Вообще-то будет, начиная с 7.4 , страницы 8-11. оно как то крайне специфически работает... местами работает а местами нет... и я уже начал исходить из того что проще вписать доп условие руками чем надеятся на то что оно вот тут вот сработает (потому что если не сработает - будет грустно а от лишнего условия очень вряд ли станет хуже). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2015, 05:00 |
|
||
|
Почему оптимизатор может не использовать индексы в партиции?
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukvyegorovпропущено... Вообще-то будет, начиная с 7.4 , страницы 8-11. оно как то крайне специфически работает... местами работает а местами нет... и я уже начал исходить из того что проще вписать доп условие руками чем надеятся на то что оно вот тут вот сработает (потому что если не сработает - будет грустно а от лишнего условия очень вряд ли станет хуже). Я согласен. Сам всегда стараюсь писать условия с избыточностью, чтобы облегчить жизнь планировщику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2015, 09:56 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38880750&tid=1998169]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
211ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 574ms |

| 0 / 0 |
