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

On Wed, Apr 27, 2011 at 6:26 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> 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:

Note that I also created all the triggers to put the rows into the
right tables as well.

> 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.
>



--
To understand recursion, one must first understand recursion.