powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Почему оптимизатор может не использовать индексы в партиции?
22 сообщений из 22, страница 1 из 1
Почему оптимизатор может не использовать индексы в партиции?
    #38880723
kamakama
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброе время суток. Есть 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.
SELECT
			id_article,
			id_spr_object,
			key_in_spr,
			rank
		FROM
			indexed_result ir, spr_article_old sa
		WHERE
			ir.id_article = sa.id


Планировщик отказывается от использования индекса, выдавая следующий результат
"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
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880738
kamakamaВопрос - как заставить Postgres использовать индексы
стесняюсь спросить - а на.для.зачем ?
kamakama... и делать это достаточно эффективно? Размеры индексов таковы, что они все целиком влезают в shared_buffer
-- в данном случае никак -- все рано ему за каждой запись-пись потом на диск лазать.
Дешевле прочитать все одним куском, как он и делает.
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880750
/\/\/\/\/\/\
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kamakama,

Кстати, что Вы собираетесь делать с 9 млн. записей на клиенте?

Что будет, если вовсе отказаться от разбиения на партиции?
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880758
kamakama
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
/\/\/\/\/\/\,

Нет, это не для клиента, это один из подзапросов более большого запроса, выполняемого на стороне сервера. Сам большой запрос генерируется полуавтоматически, поэтому возможностей по его модификации немного. Конечный результат - не более 100 строк.
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880783
/\/\/\/\/\/\
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kamakama,

Ога. Таким образом, 9 млн строк где-то сохраняются в недрах сервера, затем фильтруются и выводится результат в 100 строк. Сохранение явно идет на диск, затем там же на диске идет сортировка и отбор всего этого так же явно по диску.
А Вы беспокоитесь о каких-то индексах.
Стоит ли беспокоиться о том, что не можете изменить?
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880799
kamakama
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Меня больше интересует другое. Почему оптимизатор снача склеивает все части партиции, а потом накладывает ограничение? Почему он не применяет их последовательно к каждой части партиции и не склеивает полученые результаты?
Вообще, у меня сложилось впечатление, что в части работы с партициями оптимизатор не очень хороший. В частности, идентичные по смыслу и результату запросы выполняются совершенно по разному
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT
	id_article,
	id_spr_object,
	key_in_spr
FROM
	indexed_result ir, (select id from spr_article_old ) sa
WHERE
	ir.id_article = sa.id
	and ir.id_article > 1900000


Выдает
"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.
SELECT
	id_article,
	id_spr_object,
	key_in_spr
FROM
	indexed_result ir, (select id from spr_article_old ) sa
WHERE
	ir.id_article = sa.id
	and sa.id > 1900000


"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)"
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880801
kamakama/\/\/\/\/\/\,

Нет, это не для клиента, это один из подзапросов более большого запроса, выполняемого на стороне сервера. Сам большой запрос генерируется полуавтоматически, поэтому возможностей по его модификации немного. Конечный результат - не более 100 строк.
вам надо или руками инжектировать сюда те фильтры, которые оставляют в итоге "не более 100 строк"
или оставить возможность серверу спланировать перенос условий сюда (т.е. не совать запрос в CTE)

и в том и в другом случае вопрос об оптимизации запроса на 9 лямов записей не стоит.
а то, что нужно/можно оптимизировать, -- мы не увидели.


в общем то всё искусство писания запросов в том и состоит -- дать планеру как можно раньше эффективно отфильтровать наборы, которые (уже маленькие) потом можно вертеть очень неоптимально -- это уже не важно.
Т.е. вы конечно имеете дело с множествами и декларациями. Но в реализации -- не декларации, а алгоритмы.
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880803
kamakama
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
/\/\/\/\/\/\,

Вообще да, можно поэкспериментировать с настройками postgresql.conf. Типа work_mem. Но по хорошему - почему это все добро не кладется в shared_buffer? места там завались - 16 GB
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880807
kamakama
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
интересуюсь,

Это то понятно, что чем больше отсечешь в начале, тем меньше промежуточные объемы и быстрее результат. Возможностей для этого мало - автогенерация кода увы не дает простора для творчества, точнее, его очень мало
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880821
kamakamaинтересуюсь,

Это то понятно, что чем больше отсечешь в начале, тем меньше промежуточные объемы и быстрее результат. Возможностей для этого мало - автогенерация кода увы не дает простора для творчества, точнее, его очень мало
вот мы и нашли корень проблемы.
боритесь с автогенерацией
, либо приданием ей требуемой интеллектуальности (что чуть более, чем творчество )
, или искоренением недостаточно гибкой

как я понимаю -- взяли известное поделие криворуких овнокодеров (коих -- чуть более, чем все), и теперь успешно с ним боретесь.
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880837
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880840
kamakama,
и да, оптимайзер, с т.з. разноса условий по inner join-у в pg далеко не торт.
вы сами видите -- то он одну таблу по индексу берёт, то другую.
а чтобы обе -- надо оба условия писануть --- тогда всё будет чики-поки

мало индусов в опенсорсе, не башляет им жадный буржуин ларри элисон
такого много чего есть, не реализованного из "удобств"
но механизмы (реализованные) есть [есть упорные ребята - пишут], и достучаться до них можно руками
и , стало быть, автоматику сбора запросов, без учёта этих проблем ,эффективно не написать
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880852
kamakama
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
интересуюсь,

Ну, не совсем овнокодеры это писали. Суть однако не меняется - как можно перестроить маленький подзапрос (как вариант - поковырять настройки postgresql.conf), чтоб бы все это хозяйство крутилось в памяти. Все таблицы в сумме занимают не более 3 GB в целом и 4 - вместе с индексами.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
SELECT
	id_article,
	id_spr_object,
	key_in_spr
FROM
	indexed_result ir, spr_article_old sa
WHERE
	ir.id_article = sa.id
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880866
kamakamaинтересуюсь,

Ну, не совсем овнокодеры это писали. этого не может быть, потому что не может быть никогда.
любой имевший дело с линуксами или виндой это знает
а кто оракл видал -- тот в цирке не смеётся
ну и т.д.
пишите свой генератор, прикручивайте свои фичи

как вариант -- садитесь за си, исходники постгреса -- и вперде -- патчить планировщик
там миллионы человеко--часов не затрачены
kamakamaСуть однако не меняется - как можно перестроить маленький подзапрос (как вариант - поковырять настройки postgresql.conf), чтоб бы все это хозяйство крутилось в памяти. Все таблицы в сумме занимают не более 3 GB в целом и 4 - вместе с индексами.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
SELECT
	id_article,
	id_spr_object,
	key_in_spr
FROM
	indexed_result ir, spr_article_old sa
WHERE
	ir.id_article = sa.id


вы пишете такой подзапрос, который не нужно и даже вредно оптимизировать. пока вы этого не понимаете, вам ни генератор писать, ни сами запросы -- незачем. вам метлу надо осваивать. и в клининг менеджеры трудоустраиваться. благо - гастеры поразбежались.
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880870
/\/\/\/\/\/\
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kamakama,

За это отвечает параметр work_mem ( RTFM ). К размещению 9 млн записей в памяти отношусь крайне скептически.

Может быть писали опытные и аккуратные разработчики. Но цели и параметры оценки их работы явне не совпадают с Вашими. Поэтому результат немного предсказуем.
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880896
kamakama
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
/\/\/\/\/\/\,

Это все ясно. Я в общем то тоже. Просто сейчас пограничное состояние или пилить как есть по мелочам, или радикально менять на OLAP. Склоняюсь к последнему
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38880940
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Bogukkamakama,
Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c.
Вообще-то будет, начиная с 7.4 , страницы 8-11.
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38881016
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorovMaxim Bogukkamakama,
Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c.
Вообще-то будет, начиная с 7.4 , страницы 8-11.

Круть, а чего он тогда IS NOT NULL в соседней теме не выводит? :)
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38881037
vyegorovMaxim Bogukkamakama,
Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c.
Вообще-то будет, начиная с 7.4 , страницы 8-11.
проверил -- вроде бы да, работает. но только если типы совпадают. но если типы не совпадают -- это было бы видно в планах для предложения фильтра. а этого тоже не видно.

в случае равенства -- еще работает, в случае неравенства, как у автора, сразу вырождается в сек-скан по партициям той, по которой не указано.

там недописано что-то для разных операторов, в планере. Может быть лейн ешё что-то подкрутит со временем.

для непартицированной -- тоже (сек скан), если вторая -- партицирована. но индекс скан -- если вторая сингл.
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38881042
Nitro_Junkievyegorovпропущено...

Вообще-то будет, начиная с 7.4 , страницы 8-11.

Круть, а чего он тогда IS NOT NULL в соседней теме не выводит? :)

потому, что это другой оператор. То, что он так же позволяет перенос -- надо отдельно писать.

особо доставляет то, что IS NOT DISTINCT индексами не охвачен (особо -- для сравнения компаундов индексных полей)
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38881250
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorovMaxim Bogukkamakama,
Даже из a=b and b=c оптимизатор за вас не будет выводить and a=c.
Вообще-то будет, начиная с 7.4 , страницы 8-11.

оно как то крайне специфически работает... местами работает а местами нет... и я уже начал исходить из того что проще вписать доп условие руками чем надеятся на то что оно вот тут вот сработает (потому что если не сработает - будет грустно а от лишнего условия очень вряд ли станет хуже).
...
Рейтинг: 0 / 0
Почему оптимизатор может не использовать индексы в партиции?
    #38881347
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Bogukvyegorovпропущено...

Вообще-то будет, начиная с 7.4 , страницы 8-11.

оно как то крайне специфически работает... местами работает а местами нет... и я уже начал исходить из того что проще вписать доп условие руками чем надеятся на то что оно вот тут вот сработает (потому что если не сработает - будет грустно а от лишнего условия очень вряд ли станет хуже).
Я согласен. Сам всегда стараюсь писать условия с избыточностью, чтобы облегчить жизнь планировщику.
...
Рейтинг: 0 / 0
22 сообщений из 22, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Почему оптимизатор может не использовать индексы в партиции?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]