Привет. Есть какие нибудь рецепты как снизить время планирования при

использовании секционирования в PG 12? Тестируем переход с одной плоской 1ТБ таблицы на секции , планинг тайм скачет от 10мс до 600мс, что довольно большой оверхед.

Хмм... а не должен бы (при стабильной нагрузке и подходящих запросах). А сколько секций, и это те же самые запросы? Можете показать планы?

секций чуть больше 100 (ключ - дата, нарезаны по месяцам). Чем больше секций попадает под условие- тем выше планнинг тайм

планы там простые, индекс скан по каждой секции. Вот думаю что схема не очень оптимальная. Где то читал что чем шире таблица - тем хуже. В таблице 50 колонок

Ну так это так и будет (чем больше план, тем дольше его создавать)... Вопрос-то в другом — это стабильно происходит для тех же планов (и т.п.)?

Запросы одинаковые. Просто нагрузка больше похожа на oltp - 10-50мс - 90% запросов. И жертвовать еще до 500мс на планнинг, как то не очень. Есть выигрышь на небольшом кол-ве запросов которые возвращают большое кол-во строк, но их меньше 10%. В общем секции не про oltp видимо ...

Там сложность в том, что при планировании для каждой секции берётся lwlock на схему. Поэтому оно может неожиданно и произвольно вставать в ожидании блокировки.

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

> Запросы одинаковые. Да я не об этом... вот если повторить 4 раза тот же запрос (один из "проблемных") — у него время планирования примерно одинаковое или нет? > В общем секции не про oltp видимо ... Как будто у Вас есть другой выход (если это более-менее типичная ситуация) при таблицах такого размера (без адекватного обслуживания всё это будет работать ещё хуже, скорее всего). :(

Да, одинаковое. Как вариант проверю с меньшим количеством секций. Разбив по годам

Под нагрузкой спинлоки ведут себя вот так. Это нормально, но плохо :)

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

Так там всё каждый раз одинаковое, как видите. Т.е. locks вообще ни при чём, по идее (если это и на тесте / с одним клиентам тоже так).

примерно такая схема, вырезал индексы и один фк. Триггеров и прочих извращений нет. https://pastebin.com/qxmixy1J в запросах всегда есть условие по acckey & sdate

(Дошли руки) Хмм... а зря вырезали, видимо. См. https://dpaste.org/FydG Как-то всё быстро, на первый взгляд...

Ну 11мс тоже не мало, на плоской было меньше 0.5мс. Но все равно спасибо, есть над чем подумать. У вас минорная версия какая?

Опять-таки, тут уж ничего не поделаешь — медленнее планировать, когда сотни таблиц (в том же примере, если попадает в план только 1 таблица — это 1 мс, если 12 — 2 мс.). Версия 12.4.

У меня 12.1. Надо на 12.4 проверить на всякий

Зачем Вы на не актуальном minor вообще сидите — проблем в жизни мало? ;) Может быть, что там исправили какой-то bug, в самом деле (но, скорее всего, всё-таки индексы и FK "виноваты" — чем их больше, тем планирование медленнее).

Такова политика rhel, и его пакетов в стрим 😔

Что?! ;) Т.е. они поставляют продукт с публично известными security issues?! https://why-upgrade.depesz.com/show?from=12.1&to=12.4 "Здорово", если так.

Есть же pgdg пакеты для rhel

Да, но к сожалению, пока условия не позволяют использовать.