Re: Re: best practice for moving millions of rows to child table when setting up partitioning?

Поиск
Список
Период
Сортировка
Искать
От
Scott Marlowe
Тема
Re: Re: best practice for moving millions of rows to child table when setting up partitioning?
Дата
Msg-id
BANLkTimihm0e4DewUxkSZ_YNs4wkK8VpZA@mail.gmail.com
Ответ на
Список
Дерево обсуждения
best practice for moving millions of rows to child table when setting up partitioning? Mark Stosberg <mark@summersault.com>
Re: best practice for moving millions of rows to child table when setting up partitioning? Bob Lunney <bob_lunney@yahoo.com>
Re: best practice for moving millions of rows to child table when setting up partitioning? Mark Stosberg <mark@summersault.com>
Re: Re: best practice for moving millions of rows to child table when setting up partitioning? Scott Marlowe <scott.marlowe@gmail.com>
Re: Re: best practice for moving millions of rows to child table when setting up partitioning? Mark Stosberg <mark@summersault.com>
Re: Re: best practice for moving millions of rows to child table when setting up partitioning? Scott Marlowe <scott.marlowe@gmail.com>
Re: best practice for moving millions of rows to child table when setting up partitioning? Raghavendra <raghavendra.rao@enterprisedb.com>
Re: best practice for moving millions of rows to child table when setting up partitioning? Mark Stosberg <mark@summersault.com>
Re: Re: best practice for moving millions of rows to child table when setting up partitioning? Greg Smith <greg@2ndQuadrant.com>
Re: best practice for moving millions of rows to child table when setting up partitioning? Mark Stosberg <mark@summersault.com>
Re: Re: best practice for moving millions of rows to child table when setting up partitioning? "ktm@rice.edu" <ktm@rice.edu>
Re: Re: best practice for moving millions of rows to child table when setting up partitioning? Scott Marlowe <scott.marlowe@gmail.com>
Re: Re: best practice for moving millions of rows to child table when setting up partitioning? Scott Marlowe <scott.marlowe@gmail.com>
I had a similar problem about a year ago,  The parent table had about
1.5B rows each with a unique ID from a bigserial.  My approach was to
create all the child tables needed for the past and the next month or
so.  Then, I simple did something like:

begin;
insert into table select * from only table where id between 1 and 10000000;
delete from only table where id between 1 and 10000000;
-- first few times check to make sure it's working of course
commit;
begin;
insert into table select * from only table where id between 10000001
and 20000000;
delete from only table where id between 10000001 and 20000000;
commit;

and so on.  New entries were already going into the child tables as
they showed up, old entries were migrating 10M rows at a time.  This
kept the moves small enough so as not to run the machine out of any
resource involved in moving 1.5B rows at once.
В списке pgsql-admin по дате отправления
От: ktm@rice.edu
Дата:
От: Scott Marlowe
Дата:
FAQ