On Wed, Sep 2, 2009 at 6:30 AM, Jaime
Casanova<jcasanov@systemguards.com.ec> wrote:
> On Tue, Sep 1, 2009 at 9:55 PM, Robert Haas<robertmhaas@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
