Секционирование

Всем привет! Помогите решить такую задачу!
Есть таблица заказов клиентов, которую хочу секционировать, но по "хитрому".
Чтобы была одна секция в которую всегда был insert по-умолчанию, а по мере "старения"
данных, перемещать их вручную в "архивные" секции.
Объясню зачем так:
Мне удобней написать SELECT ONLY FROM, чтобы получить "живые" данные, а для получения данных из архива
просто SELECT FROM.
С декларативным описанием Postgres 12 не могу получить такую структуру таблицы (и соответственно всех ее подчиненных).
А если идти через INHERITS, то писать доп. триггеры не очень хочется.

P.S> Сейчас сделано через схемы: 2014-год,2015-год... и чтобы выбрать данные по всей базе (шеф просит) нужно писать через union

Заранее спасибо!

0

Мне видится, что при таком желании только вручную делать.
Для стандартного декларативного подхода так не полчится сделать.
Хотя не очень ясно желание в принципе разделять запросы.
Пишите одинаково, а уже в какую партицию попадет - это база сама решит.
В этом собственно и смысл.

0

Спасибо! Уже помогли найти решение.
Вручную - не так страшно, как ждать .... ответа от сервера
Я просто приучил своих пользователей мгновенной реакции программы
на их действия и они теперь при малейшей задержке все бегут ко мне.
А я устал отвечать - база пухнет и т.д.

0

Если не затруднит, опубликуйте тут решение.
Чтоб помочь другим людям в решении их проблем.

0

Без проблем! И так моя задача (для меня) была такой.

Исходные данные:
- Есть заказы клиентов (таблица)
- Есть продукты заказов (таблица)
- Есть материалы продуктов (таблица)
- Есть операции над материалами (таблица)
- Есть характеристики (параметры) продуктов (таблица)
- "пухнут" как и у всех

Желания:
- Разделить заказы на "живые" и "архивные"
- Доступ к данным через один и тот же запрос
- Скорость выборки-отклика программы
- Использовать минимальное количество телодвижений при дальнейшем обслуживании
- Индексы это хорошо, но маленькие индексы - лучше (опять таки - для меня!)
- Я сам должен решать когда "живые" данные становятся "архивными".
- При добавлении новых полей, они должны быть и в архиве для отработки одних и тех же запросов

P.S. Приучил своих пользователей к комфортной работе. А теперь при малейших задержках - бегут и кричат тормозит!!

Решение:
- Использовал декларативное объявление таблиц. ()
- Создал все таблицы и разбил на 2 уровня вложенности. Первый уровень: года - 2010, 2011, ... Второй уровень: ID (от 1..10, 11..20, ....)
- Для "живых" данных использую год 2000, для остальных - реальный.
- Вставка данных с учетом разбиения идет автоматом, благодаря самому Postgres.
- Внешние ключи с версии 12 теперь можно подключать к конкретным секциям, т.е. целостность БД сохраняется.
- Индексы уменьшились
- Очень старые данные можно отключать (использовать не буду, т.к. шеф у меня любит статистику )
- Во всех запросах (по-тихоньку и где нужно) пропишу дополнительное условие: и база начнет выборку только в нужном маленьком диапазоне. А в конкретных случаях вообще - - Ну, осталось дело за малым, перемещение данных между годами. Это вручную (как и раньше с помощью функции). Для БД это не хорошо, но у нас есть окна, в которых можно это делать без особой нагрузки на сервак.

Как-то так! Я не претендую ни на что, я лишь рассказал какое решение меня устроило.
Спасибо!

0