From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Mark Stosberg <mark(at)summersault(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Re: best practice for moving millions of rows to child table when setting up partitioning? |
Date: | 2011-04-28 00:26:58 |
Message-ID: | BANLkTinxPMAOqVMH+rPX=Wpoa+dWxEWgjQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Wed, Apr 27, 2011 at 6:26 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ray Stell | 2011-04-28 02:03:56 | Re: Please, i want exit here |
Previous Message | Scott Marlowe | 2011-04-28 00:26:14 | Re: Re: best practice for moving millions of rows to child table when setting up partitioning? |