Как стать автором
Обновить

Комментарии 20

Не будет ли вам трудно у «обычной» таблицы создать индекс по дате и провести тест еще разок? Если бы вы explain analyze приложили, было бы вообще шикарно.
Analyze к «обычной» таблице
image

Analyze к секционированной
image

UPD: на предыдущем скрине, тест.сервер, там данные были удалены, приложил актуальный скрин
Analyze к секционированной


Надеюсь, на скринах будет видно
Замечательно видно что вы тестируете в неравных условиях. См. actual rows.
Все верно замечено, исправил.
Вот только разница в 22 раза это все равно очень много и не объясняется секционированием. Разные конфигурации бд?
Да, нужно ориентировать на цифры в статье см. таблицу в разделе Результат. Отклонения от этого объясняется разными конфигурациями сервера.
Цифры в статье тоже слишком большие, не должно быть такого прироста. Поэтому я и спрашиваю.
Секционирование не является решением, которая способна дать профит для любой базы. Могут быть случаи, когда это отразится плохо на производительности. Для принятия такого решения нужно оценить все риски, если вы не получаете желаемого результата, то возможно это не то что вам нужно.
Слишком общие не подкрепленные у вас заявление, ответ ради ответа. Я в курсе всех особенностей, а вот ваши цифры все равно выглядят завышеными.
Сначала пришел в ужас от разницы в 220 раз, потом заметил, что во втором случае 0 строк, не пойдет)
в 12 версии есть поддержка ссылок на секционированную таблицу. Это большой прорыв

Как оказалось, не такой уж и большой, т.к. в этом случае первичный ключ секционируемой таблицы должен содержать поле, по которому поисходит секционирование. А это очень печально.
Это справедливо и для 11 версии. Можете уточнить?
что уточнить? на собственном опыте проверили на PG 12.
в PG 11 нельзя было создать первичный ключ без ключа секционирования, а PG 12 просто появилась возможность ссылаться на такой ключ (создавать внешний ключ).

вот еще пруф fragland.dev/a-guide-to-table-partitioning-with-postgresql-12

Это было далеко не просто, но в целом вы правы. Первичный ключ содержит ключ секционирования, не вижу в этом проблемы.
Это может быть сложно, если вы не знаете правила по которому можно определить этот ключ.

Сложно, когда в рабочей схеме БД решили сделать секционирование таблицы — придется менять не только эту таблицу, но и структуру таблиц, ссылающихся на нее (добавлять во внешние ключи поле, не относящееся к этим таблицам), менять логику их заполнения и обращения к ним.
Проще тогда попытаться сделать FK на триггерах…
Другими словами, мы отбросили эту идею в долгий ящик.

Спасибо за ответ. Я ещё не реализовал у себя нативную поддержку FK 12 версии. Использую решение на триггерах.

Очень интересное решение, спасибо!
Не увидел в коде поддержки DEFAULT партиций.
Это в списке TODO или отстутствует по каким-то другим причинам?
DEFAULT партиция не создается, определяю MINVALUE/MAXVALUE как нижняя и верхняя граница.
Как вы решили у себя проблему создания новых секций?
Мы создали такой «job», на основе pg_cron, который 1 раз в день (у нас секционирование по 1 дню используется) добавляет новую секцию к таблице.
У нас еще нет этой проблемы, но cron выглядит как хорошее решение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий