Нет возможности задавать шаблон названий дочерних таблиц

[socketpair]

Например, для разбивалки по диапазонам - я хочу некоторые операции делать над фактическими таблицами. А где взять их имена ? Вдруг в следующей версии схема именования поменяется ?

Ну, и пачка идей:

Нет возможности указывать шаблон названия тейблспейса для каждой создаваемой таблицы. Либо нужен триггер в котором можно переместить таблицу (это возможно из триггера?).

Ещё, из идей - чтобы при выборках из виртуальной таблицы был дополнительный виртуальный столбец - имя фактической таблицы.

Кстати, не по теме, а там нет оптимизации, что при удалении записей в диапазоном разбиении - если выясняется что все записи из некоторой таблицы будут удалены, то проще сделать drop table, чем удалять из таблицы всё.

и ещё, в документации нужно указать полный список того, что копируется с главной таблицы, а что нет во время создания реальных. Фантазирую, конечно, но вдруг какой-то признак типа unlogged, fillfactor или autovacuum не копируется (не проверял).

Не документировано как формируется название индексов при копировании с мастер-таблицы.
Если в мастер-таблице было запомнено что кластеризовать по этому индексу, это перенесётся в дочерние таблицы (должна смениться ссылка на новый индекс)?

ещё, ранее я находил https://github.com/keithf4/pg_partman и там ведётся работа. у кого лучше ? есть ещё https://github.com/moat/range_partitioning

[zilder]

А где взять их имена ?

Вы бы хотели, чтобы была функция или вьюшка, которая бы возвращала список партиций и соответствующих интервалов? Это несложно добавить.

Ещё, из идей - чтобы при выборках из виртуальной таблицы был дополнительный виртуальный столбец - имя фактической таблицы.

В списке атрибутов SELECT-а можно указать скрытый столбец tableoid, который возвращает OID фактической таблицы. Из него несложно получить имя. Например:

SELECT tableoid::regclass, * FROM MyTable;

Вы это имели в виду?

... то проще сделать drop table, чем удалять из таблицы всё.

Боюсь, такая дополнительная проверка может замедлить остальные запросы на удаление.

Фантазирую, конечно, но вдруг какой-то признак типа unlogged, fillfactor или autovacuum не копируется (не проверял).

Проверил, действительно не копируется. Подумаем, что с этим делать.

ещё, ранее я находил https://github.com/keithf4/pg_partman...

Мы изначально ставили целью оптимизацию работы планировщика для большого числа секций (сотен и тысяч). pg_partman предоставляет администратору удобные средства для разбиения и управления секциями, но он не решает проблему производительности, присущую postgresql. Вот здесь @akorotkov публиковал сравнение производительности pg_pathman и pg_partman: Pg_pathman UPDATE and DELETE Support and Benchmark

[socketpair]

Вы бы хотели, чтобы была функция или вьюшка, которая бы возвращала список партиций и соответствующих интервалов?

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

В списке атрибутов SELECT-а можно указать скрытый столбец tableoid

Да, похоже, что я это имел в виду. Надо добавить это в пример (readme.md) как сделать запрос чтобы получить в итоге таблицу:

select *, xxx from megatable ....

record1 | col1 | col2 | "real_table_name1"
record2 | col2 | col3 | "real_table_name1"
record3 | col3 | col4 | "real_table_name2"

Боюсь, такая дополнительная проверка может замедлить остальные запросы на удаление.
Если это возможно, то сделать нано-оптимизацию для следующего кейса

Если сделали delete from megatable where column_for_range_split between xxx and yyy (или аналогичный) И диапазон полностью покрывает реальную таблицу, то делать drop real_table .

Если же условия удаления более сложные (даже приводящие к полному удалению записей из реальной таблицы) то указанную мной оптимизацию не включать.

Реальный юзекейс - удаление старых записей из статистики. удалению будет именно такое "Удалить все записи старее такой-то даты". Ну и разделение, естественно, под столбцу с таймстампом.

Проверил, действительно не копируется.

Тогда нужно отписать явно в документации что именно копируется (наследуется) а что нет. И написать что работы над этим ведутся.

здесь @akorotkov публиковал сравнение производительности

считаю это достойным документирования.

[socketpair]

Вы сами создадите на каждую подзадачу issue или это лучше мне сделать ?

[zilder]

Лучше создайте вы и опишите юзкейсы. Спасибо за отзыв!