Хочу ускорить выполнения запроса. Подскажите, пожалуйста, как это можно сделать? 1.

Версия Postgres — 12.5
2. Запрос — https://pastebin.com/qchr3RSe
3. \d каждой используемой таблицы — https://pastebin.com/eHdPkiXy
4. План запроса — https://pastebin.com/ictUie93

Я думал в сторону секционирования таблицы по event_id Мб, кто-то другое, более изящное решение предложит

Не в тему оптимизации запроса, но мне больно смотреть на условие по дате sm_table_1.datetime <= '2022-07-26 23:59:59' Время 26 июля 23:59:59.001-23:59:59.999 ехидно улыбается где-то в стороне, ДБА рвет волосы на голове, а бизнес пытается найти для клиента, оплатившего счёт, оправдание, почему в системе счёт светится неоплаченным, параллельно разрывая телефоны техподдержки платежного агента Но это так, мысли вслух

@Setplus_seC А действительно, почему не datetime < '2022-07-27 00:00:00.000'

сделал — https://pastebin.com/JkrPawaF вверху — план для множественного OR внизу — план для запроса, где множество OR заменены на IN

Очень странно, что во втором случае был использован pkey

Согласен. Индекс я честно создал CREATE INDEX ON some_table_1 USING btree(datetime, event_id) INCLUDE(id);

Скорее всего, запросы просто к разным базам отправлены. Можэт, правда, в процэссе там analyze кто-то запустил, не знаю.

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

Одна и та же база.

После создания индекса выполнил оба запроса,

Ерунда какая-то. Запросы разные из-за разных оцэнок количества столбцов по условию (4.9 млн vs 4.6 млн) -- а они по идее оцэниваются одинаково что в OR с константами что в ANY с константным массивом. Ладно, это на самом деле тут вообще не важно.

Вообще, некоторая проблема этого захода -- в том, что у вас тут везде фиаско какое-то. Логичный индэкс неиспользуется. index-only скана нет. Параллелизма нет. Дисковая подсистема тормозит как в 90-х. В таблицэ куча каких-то мусорных индэксов. Вкрячена какая-то сортировка с лимитом -- непонятно, зачем и на что она влияет. И ещё автор всего это дела заявляет, что индэксы на основные поля, по которым идёт поиск и выборка -- не приведены, поскольку не имеют значения. В ситуацыи такого полного фиаско, конечно, любое осмысленное действие будет улучшать ситуацыю. Но это не значит, что это осмысленное действие будет разумным.

Подробнее отвечу завтра по каждому пункту. В любом случае, большое человеческое спасибо, что помогаете разобраться, т.к. я сам порядком запутался..

Да я ещё и спрашывать не начал.

отвечу —> прокомментирую

1.Второй тожэ глубоко безсмысленнен при наличии первого. 3. Думать, что мешает серверу, пытаться (хотя бы не запуская, чисто explain) смотреть, при каких условиях хоть что-то работает параллельно, и вообще postgres способен так работать, смотреть, при каких условиях оно ломается и как совместить бизнес-требования и параллельность. > 4. ... CEPH Источник боли понятен и очевиден. Если интересует скорость -- просто не делайте так, конечно. Хотя конкретно этот запрос вероятно сможэт отработать с приемлемой скоростью через index-only range scan -- всё равно, у вас там ещё детализирующий запрос, с ним примерно в любом случае будет плохо всё.

Как я понял, пока что единственный вариант ускорить запрос — сделать секционирование таблицы

Ну, поняли и поняли.

Спасибо за уделённое время!

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

Не очень понял, если честно, о чём идёт речь. Не могли чуть подробнее написать?

Читать примерно вот этот раздел: https://www.postgresql.org/docs/current/runtime-config-query.html Весь и вдумчиво. И да, если у вас необычная система -- то правильные косты тожэ будут необычными... ЗЫ Кстати, что у вас говорит SELECT name, setting, unit FROM pg_settings WHERE name LIKE '%cost'; ?

Почему? Готов исправиться.

Потому, что помнится индэкс был (event_id, datetime, id).