Re: Eliminating VACUUM FULL WAS: remove flatfiles.c - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
Date
Msg-id 603c8f070909042003p6c0b9768t9667266c12f80c1@mail.gmail.com
Whole thread Raw
In response to Re: Eliminating VACUUM FULL WAS: remove flatfiles.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Sep 4, 2009 at 9:37 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> Hmm ... reading that over again, it seems like there is a pretty
>>> obvious solution.
>
>> This doesn't seem totally horrible.  But, before you go do it, do we
>> have a clearly-defined plan for the rest of the project?
>
> Rest of what project?  Removing vacuum full isn't a necessary component
> of that.  It would enable doing CLUSTER on pg_class, and it would
> eliminate the crock of REINDEX having to reindex shared indexes
> in-place.  It could probably be justified even without any changes in
> our approach to vacuum.

OK, I'm sold.

>> ... only need this if we're absolutely confident that rewriting the table
>> in place is just not an option worth keeping around.  It's unclear to
>> me that everyone is convinced of that, and even if they are, it's
>> unclear to me what we plan to implement instead.
>
> I thought we were pretty well agreed that a seqscan variant of
> CLUSTER would be worth doing.  Whether we take the next step by
> eliminating vacuum full is a different question, but the shape of
> the substitute seems perfectly clear.

Well, there were some other ideas discussed, but perhaps that's the
only one that had a clear consensus.

...Robert


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
Next
From: Robert Haas
Date:
Subject: Re: match_unsorted_outer() vs. cost_nestloop()