- Автоматическое распределение данных по партициям, а также чтение, обновление и удаление данных без единой правки кода.
- Автоматическое обновление структур партиций (индексы, ограничения (constraints), триггеры, правила (rules) и т.д.).
- Удобные и гибкие миграции для больших команд с большим количеством данных, хранимых процедур, представлений, таблиц, типов, миграций, дельт и т.п. Как это всё организовать и поддерживать?
- Инструменты и утилиты, которые мы используем для вышеперечисленных целей.
21. Status Quo
Currently we allow the user to (manually) create arbitrary nested tables with arbitrary constraints and then the planner tries to detect at
run-time which child tables are candidates for the query. See PostgreSQL Partitioning for details. There are some 3rd party plugins that simplify
the (manual) task/triggers, etc. see bottom of this page.
Today, at create time you create a master table, children that inherit from it (and how they are partitioned), separate indices for each child table,
and create an insert trigger so that new rows are inserted to the appropriate (child) table (and/or more aggressive measures, such as allowing
updates to the partitioned key [by default, updates to rows' partitioned key leave them in the same partition, possibly in error], dynamically
allocating new child tables [be careful with race conditions], etc. see the various blogs out there).