сделать DROP TABLE при удалении всех строк реальной таблицы

[socketpair]

#5:

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

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

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

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

[funbringer]

Это есть в планах, но придется подождать.

[ildus]

Не лучше ли сделать отдельную функцию для этого? Которая может удалять таблицы по диапазону.

[funbringer]

Не лучше ли сделать отдельную функцию для этого? Которая может удалять таблицы по диапазону.

Такая уже есть: drop_range_partition(), просто нужно выполнить ее по pathman_partition_list. Пример:

select drop_range_partition(partition)
from pathman_partition_list
where parent = 'test'::regclass and range_min::int < '100';

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

[ildus]

Кажется очень неправильным делать неявный DROP TABLE если запрос при этом DELETE FROM. Опять же никто не гарантирует что паралельно не попытаются вставить строки в удаляемые таблицы.

[ildus]

@funbringer я думаю можно закрыть этот issue, раз она решается функцией и это будет правильным способом.

[funbringer]

@funbringer я думаю можно закрыть этот issue

Пожалуй.

Я думаю, было бы хорошо добавить небольшое пояснение. Мне кажется, что идея не выгорит, и тому есть несколько причин:

• Оптимизация применима только к RANGE-партицированию;
• При удалении партиции образуется "дырка", в которую будет нельзя вставить данные. Хотя на ее месте можно будет создать новую партицию вручную, это не очень удобно;
• При удалении партиции до конца транзакции будет удерживаться блокировка уровня AccessExclusive, в отличие от RowExclusive. Разница существенная - в других сессиях нельзя будет обновить наш кеш.