Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
 Секционирование  [new]
Squamis
Member

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

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

Заранее спасибо!
2 мар 21, 15:40    [22288444]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
vyegorov
Member

Откуда: Баньоло-ин-Пьяно
Сообщений: 1233
Squamis,

Вы хотите очень странного. Зачем вам движение всех данных по прошествии какого-то времени, если оно “само” так работает?

Если сделать обычное RANGE секционирование, скажем, по месяцам, то все INSERT-ы будут всегда лететь в заведомо известную секцию (никаких триггеров не надо даже). И выбирать можно из текущей партиции, хотя я тут тоже не вижу никакого смысла.
2 мар 21, 16:37    [22288495]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
Squamis
Member

Откуда:
Сообщений: 8
Согласен, полностью.
Но, хочу чтобы в основной части программы все "летало", используя только "живые" данные.
А в статистиках "шерстило" по всей базе.

Range не очень спасает, т.к. заказы могут длится 2-3 месяца, при этом он считается "живым"
и запросам придется лезть в "старые секции", а хотел бы выбирать только из одной, пока сам не решу, что заказ старый и переместить его в "архив".

Как-то так. Понимаю - бред. Но, вдруг у кого-то "мысля-идея" придет в голову :)
2 мар 21, 16:45    [22288496]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
Misha111
Member

Откуда:
Сообщений: 55
так добавьте поле статус заказа и по нему секционируйте
2 мар 21, 17:01    [22288513]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
Squamis
Member

Откуда:
Сообщений: 8
Это хорошая идея, спасибо.
А есть ли возможность у заказов со статусом "архивный" разделить на дополнительные секции. Например:

таблица orders
1. Секция - orders_live (живые заказы)
2. Секция - orders_archive (архивные заказы)
2.1. Субсекция - 2020.01 за январь
2.2. Субсекция - 2020.02 за февраль
....
2.n. Субсекция - ....
2 мар 21, 17:29    [22288535]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
Misha111
Member

Откуда:
Сообщений: 55
дока
Сами секции могут представлять собой секционируемые таблицы, благодаря применению так называемого вложенного секционирования. В секциях могут быть определены свои индексы, ограничения и значения по умолчанию, отличные от других секций. Индексы должны создаваться для каждой секции независимо. Подробнее о секционированных таблицах и секциях рассказывается в описании CREATE TABLE.


например
2 мар 21, 18:09    [22288563]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
lex-sey
Member

Откуда:
Сообщений: 9
Вопрос в продолжении темы. У кого то был опыт перемещения отдельных партиций партицированной таблицы в другое табличное пространство? Это возможно? Какие есть ограничения?
4 июн 21, 12:33    [22331295]     Ответить | Цитировать Сообщить модератору
 Re: Секционирование  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4785
lex-sey
Вопрос в продолжении темы. У кого то был опыт перемещения отдельных партиций партицированной таблицы в другое табличное пространство? Это возможно? Какие есть ограничения?


Возможно.
Никаких ограничений нет.
Если возможно на время переноса эту партицию убрать вообще из данных то будет еще и без лишних блокировок.
Последовательность операций:
ALTER TABLE [ IF EXISTS ] name
DETACH PARTITION partition_name
ALTER TABLE ALL IN TABLESPACE name [ OWNED BY role_name [, ... ] ]
SET TABLESPACE new_tablespace [ NOWAIT ]
ALTER TABLE [ IF EXISTS ] name
ATTACH PARTITION partition_name { FOR VALUES partition_bound_spec | DEFAULT }
Но лучше проверить на тестовой базе конечно.

Ну или pg_repack -s, --tablespace=TBLSPC move repacked tables to a new tablespace
в помощь там совсем легко и просто.


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
4 июн 21, 22:55    [22331667]     Ответить | Цитировать Сообщить модератору
Все форумы / PostgreSQL Ответить