Technical guidance for a large partition table

Поиск
Список
Период
Сортировка
От John Scalia
Тема Technical guidance for a large partition table
Дата
Msg-id EF56C0B6-A15B-4784-817F-60627BE46B96@gmail.com
обсуждение исходный текст
Ответы Re: Technical guidance for a large partition table  (Keith <keith@keithf4.com>)
Re: Technical guidance for a large partition table  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-admin
Hi all,

I have a dev team requesting that I partition 3 very large tables with more 2 billion rows each. I’ve already got the
partitionkey decided for each with a script which will create a copy of original with the partition declaration, along
withthe partition child tables. The problem will be that each table has an API which updates each table fairly
regularly,and the devs say it cannot be turned off. So, I’m looking for the best way to do this so that the partitioned
versionwill match the original table. FYI, this is production instance that is regularly updated by field technicians.
Quiteliterally, I cannot perform two sequential select count(*) from any of these tables which will return the same row
counts.I’m thinking of installing a trigger on insert on the original tables, which would write any insert to a third
table,then copy the original table to another table name, do the partitioning on it to yet another table name, move the
partitiontable into the original table name, kill the trigger, then apply the updates from the table where the insert
triggerwas being applied. Is there a better way to do this, or am I missing something? 
—
Jay

Sent from my iPad


В списке pgsql-admin по дате отправления:

Предыдущее
От: Vipin Madhusoodanan
Дата:
Сообщение: Re: Query on User account password change details
Следующее
От: Keith
Дата:
Сообщение: Re: Technical guidance for a large partition table