Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
От | Tom Lane |
---|---|
Тема | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |
Дата | |
Msg-id | 24852.1252114654@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
|
Список | pgsql-hackers |
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. > ... 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. regards, tom lane
В списке pgsql-hackers по дате отправления: