А мы почему не видим? (но я и не слежу особо!)

Прошу прощения, но мне можно верить на слово)

Тогда и мне поверьте: там - в плане - есть информация для сравнения и по ней можно понять "почему" был выбран тот или другой в обоих случаях.

Плохой план: Limit (cost=18.04..488920.08 rows=20 width=337) -> Append (cost=18.04..464994744.47 rows=19022 width=337) Subplans Removed: 34 -> Index Scan Backward using xxx_2023_05_01_pkey on xxx_2023_05_01 xxx_13 (cost=0.57..23794568.98 rows=36 width=313) Index Cond: ((added_at <= CURRENT_TIMESTAMP) AND (added_at >= (CURRENT_TIMESTAMP - '1 year'::interval)) AND (tenant = 1)) Filter: (related && ARRAY[('(1234567,yyy)'::xxx.id_and_type)::xxx.id]) ... + несколько партиций Хороший план: Limit (cost=21630.69..21630.74 rows=20 width=337) -> Sort (cost=21630.69..21678.25 rows=19023 width=337) Sort Key: xxx.added_at DESC -> Append (cost=0.29..21124.50 rows=19023 width=337) Subplans Removed: 34 -> Bitmap Heap Scan on xxx_2023_05_01 xxx_13 (cost=6.29..44.40 rows=37 width=313) Recheck Cond: (related && ARRAY[('(1234567,yyy)'::xxx.id_and_type)::xxx.id]) Filter: ((tenant = 1) AND (added_at <= CURRENT_TIMESTAMP) AND (added_at >= (CURRENT_TIMESTAMP - '1 year'::interval))) -> Bitmap Index Scan on xxx_2023_05_01_related_idx (cost=0.00..6.28 rows=37 width=0) Index Cond: (related && ARRAY[('(1234567,yyy)'::xxx.id_and_type)::xxx.id]) ... + несколько партиций Иногда (иногда) планировщик выбирает первый план, следующий запрос с абсолютно идентичными параметрами уже идет по второму плану. PK: added_at TIMESTAMPTZ, id UUID, tenant INT Партиционирование по added_at и tenant

В третий раз закинул он невод: https://t.me/pgsql/303899 Вы, наверное, на самом деле не хотите реальной помощи?

Ярослав, если вы хотите и можете помочь, то напишите чего именно не хватает, так как мне кажется, что я уже всю информацию по списку дал. И спасибо всем за помощь.

Можете хотя бы дать ссылки на все четыре пункта? А ещё лучше было бы собрать их все в одном месте (сообщении со вложенным файлом, или ссылкой на paste site). > ANALYZE дать не могу, так как такая настройка auto_explain Да хотя бы один план (запроса, выполненного из своей сессии) с EXPLAIN (ANALYZE, VERBOSE, BUFFERS, SETTINGS) нам покажите.

Я могу показать только explain хорошего плана. Это поможет? Я не могу получить explain плохого плана так как планировщик выбирает его довольно редко и воспроизвести руками я не могу. Я же объясняю, что один и тот же запрос с одинаковыми параметрами чаще идет по хорошему плану, но иногда без видимых причин идет по плохому

> Но кажется и так понятно Мне пока вообще ничего не понятно — потому что без полной информации смотреть бесполезно, понимаете? > Хинт все лечит Откуда это Вы в PostgreSQL взяли hint?! Вот потому-то и нужно показать все 4 (четыре! 1+1+1+1! я уже не знаю, как ещё написать :( ) пункта! > Я могу показать только explain хорошего плана. Это поможет? Да, это может помочь. > но иногда без видимых причин идет по плохому Что странно, и, скорее всего, потребуется и дополнительная информация, но сначала... см. выше.

Ну и, как вариант — тоже можете испытать на себе https://t.me/pgsql/474330 (может, хоть так мы получим нужную информацию). ;)

>Откуда это Вы в PostgreSQL взяли hint?! https://postgrespro.com/docs/enterprise/14/pg-hint-plan >я уже не знаю, как ещё написать Ярослав, прошу прощения, я понимаю, что выглядит так, что я туплю, но мне сложно дать всю информацию, почему я написал. Пожалуйста, не обращайте внимания, я не настаиваю.

Простите, к таким экспериментам на проде я не готов )

А Enterprise тут случайно в ссылке или у вас действительно он стоит?

А к чему Вы готовы? К тому, чтобы все дружно гадали, что там у вас не так (в неведомом fork-е неведомой версии и таблицах неизвестной нам структуры)? Так из этого почти наверняка ничего не выйдет, кроме траты времени участников.

С форком разобрались. Осталась версия.

14

test=# select version(); version ----------------------------------------------------------------------------- PostgreSQL 15.2-MY-EXTRA-VERSION, compiled by Visual C++ build 1936, 64-bit (1 row)

И да... а тестового сервера (копии кластера) в вашем "энтерпрайзе" нет? ;)

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

Косты в 22 раза отличаются. Про тюнинг коэффициентов хорошая мысль, спасибо