On Fri, Sep 4, 2009 at 9:37 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Sep 4, 2009 at 4:01 PM, Tom Lane<t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
