Но в какой то момент запрос сломался для определенного периода. Вместо

hash join используется nested loop.
С чем это может быть связано и как поправить ?

https://t.me/pgsql/303899

версия 9.6 серьезно нужно прислать DDL всех таблиц ? Можете просто подсказать в какую сторону копать ?

В идеале — да, нужно. Но для начала можно и без этого — покажите остальное.

А, ну если хотите просто поболтать обо всяком -- то начните читать нормальный explain. По словам, да. Так картинка, которую вы представили -- даёт очень мало информацыи, и если бы вы умели читать вывод explain, то вы бы это понимали.

Вот тут хеша вообще нету, а запрос тот же

И запрос выполняется 30 сек

В принцыпе довольно ожыдаемо. А когда первым joinится EnergyConsumers -- меньшэ? (Банальный вопрос -- всё на одном диске или есть какие-то tablespaces?)

Нежелание делать hashjoin теоретически может быть связано с недостатком workmem

Все на одном диске. На первый вопрос отвечу суть позже.

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

Увеличивал с 4мб до 500. Не помогло.

Нет, время выполнения запроса увеличилось вдвое

Ну, вдвое -- это не так чтобы большое отличие.

Возвращаясь к моему вопросу. Вот запросы и explain + DDL Версия постгреса 9.6 Почему в одном случае делается через нестед луп, а во втором через хеш ? Кол-во записей +- одинаковое во всех периодах

Ошыбка в оцэнке выборки из SiteInfos при BillingPeriod=73. Да и из SiteConnections тожэ. По идее, analyze siteinfos + analyze siteconnections должно это поправить. Кстати, запустите, и попробуйте посмотреть после. Возможно, что вмешывается какая-то ручная настройка статистики и аналитики. Но не очень представляю, чтобы такое было через просто set statistics.

И да, смотреть -- в кардинальное отличие rows= и actual rows= в неправильном запросе.

О, наконец-то тексты планов. ;) Потому что [огромная] ошибка в оценках в первом плане, сходу видно же: -> Index Scan using "IX_SiteInfos_BillingPeriodId" on "SiteInfos" site (cost=0.42..2.72 rows=1 width=169) (actual time=0.009..2.378 rows=7703 loops=1)

И да, если простые действия не помогут -- то читайте здесь https://www.postgresql.org/docs/9.6/row-estimation-examples.html , смотрите глазами на pg_statistic.

спасибо

Большое спасибо !!!! Ситуацию решило analyse "SiteInfos"; analyse "SiteConnections";

Тут меня ещё удивляет, что в 9.6 -- там жэ и настроек статистики практически не было. Как-то странно, что что-то сломано.

А. То есть, общий analyze как-то не так запускался. Да, бывает. Но вообще -- смотрите, просто analyze без параметров от суперюзера должэн это всё проделывать. Посмотрите, почему он у вас не запускается периодически.

Не подскажите куда смотреть?

Это задача autovacuum. Проверьте, включён ли он, его настройки, когда он последний раз обрабатывал таблицы (см. pg_stat_user_tables, например).

Спасибо.