Re: Copying data from table to table (cloned tables)

On 10/10/06, Jim C. Nasby <jim(at)nasby(dot)net> wrote:
>
> On Mon, Oct 09, 2006 at 05:02:07PM -0700, Bricklen Anderson wrote:
> > Fourat Zouari wrote:
> > >Hello all,
> > >Any one could suggest the best way to copy data from table to table in
> > >the same db, the reason why am seeking for this is that the first table
> > >is becoming very big, and old data has no reason why to stay there, so
> i
> > >created a cloned table but without indexes and constraints (lighter)
> and
> > >now i would like to copy 'some' data from first to second table (copied
> > >data is data older than 3 months, i have a timestamp column).
> > >
> > >In other way, i have a table called 'hotqueues' where i store fresh
> > >messages queued, once messages are treated, they stay in 'hotqueues'
> but
> > >with a flag indicating that their arent queued for treatment..
> > >so in this way, data will rest there forever, slowing down any searches
> > >in that table, the solution was to copy old messages to another table
> > >called 'coldqueues' that has the same structure as 'hotqueues' but
> > >lighter (without constraints and indexes).
> > >How to copy these data with 100% data-loose free.
> > >
> > >Thanks for any help you can provide.
> >
> > If you just want to copy the data across to the other table:
> > begin;
> > insert into table2 select * from table1 where <some criteria>;
> > commit;
> >
> > if you also want to remove that same data from table1:
> > begin;
> > insert into table2 select * from table1 where <some criteria>;
> > delete from table1 where <same criteria as above>;
> > commit;
>
> You need to be careful with this method. For what the OP wants to do it
> would probably work, but not always. The problem is that in some
> scenarios, <same criteria as above> won't necessarily return the same
> set of rows.
>
> Starting in 8.2 you'll be able to do something like
>
> INSERT INTO table2 DELET FROM table1 WHERE ... RETURNING *;
>
> The RETURNING * will return all the data that the command deleted. In
> older versions, your best bet is to store the data you're moving in a
> temporary table, and then use that to delete the exact rows.

You may want to lock the table before doing the copy/delete - that would
take care of having a record added between the copy and the delete.

If you are doing this on a regular basis, you may want to consider adding an
insert/update trigger on the original table to put a copy into the secondary
table and then all you have to do is do a simple delete from the originating
table every so often.

--
==================================================================
Aaron Bono
Aranya Software Technologies, Inc.
http://www.aranya.com
http://codeelixir.com
==================================================================