On Wed, Sep 2, 2009 at 6:30 AM, Jaime Casanova<jcasa...@systemguards.com.ec> wrote: > On Tue, Sep 1, 2009 at 9:55 PM, Robert Haas<robertmh...@gmail.com> wrote: >> >> I'm a bit skeptical about partitioning as a solution, too. The >> planner is just not clever enough with partitioned tables, yet.
Yeah, we need to fix that :) I think we're already reaching the point where the pains of dealing with partitioned tables are usually less than the pains of dealing with VACUUM FULL. > analyze and vacuum a *very* big table and even scan a huge index is > not a joke neither... Hm, not sure I see this. The sample size for Analyze is not dependent on the size of the table. Only on the stats_target. And vacuum with the VM is now going to be dependent only on the number of updates to the table, not on the size of the table. The problem use cases we have today are only when you really do have enough dead space to clean up that you want to compact the file -- but not so much that it's worth rewriting the whole table using CLUSTER or ALTER TABLE. Perhaps we should go one version with a enable_legacy_full_vacuum which defaults to off. That would at least let us hear about use cases where people are unhappy with a replacement. I did start a while ago on a replacement which used the existing rewrite mechanism to do the equivalent of cluster without changing the ordering. I forget where I left that but I could go back and look at it. I'll be busy for the next few weeks though so it won't be right away. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers