disclaimerÂ: I didn't read the presentation paper Greg Smith talked about yet, nor his partitioning chapter yet, so it might be about the same trick. Phoenix Kiula <phoenix.kiula@xxxxxxxxx> writes: > How about doing this with existing massive tables? (Over 120 million rows) > > I could create a new parent table with child tables, and then INSERT > all these millions of rows to put them into the right partition. But > is that recommended? If you're partitioning by date, for example, then what I regularly do is to consider the existing table to be the first partition with data from origin to now. Then what I do is to create a new parent table and is children, prepare the trigger(s), etc. The switch is then a light transaction which only renames the current table to say "name_past_201104", have it inherits the parent table, and finally rename the new parent table to the "name". Later on you still can rejigger your data around if you wish. With time based partitioning it's best to wait until the old partition is not the target of INSERTs or UPDATEs any more. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
