Re: Feedback on getting rid of VACUUM FULL
От | Alvaro Herrera |
---|---|
Тема | Re: Feedback on getting rid of VACUUM FULL |
Дата | |
Msg-id | 20150428184424.GD4369@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Feedback on getting rid of VACUUM FULL (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Feedback on getting rid of VACUUM FULL
|
Список | pgsql-hackers |
Robert Haas wrote: > On Fri, Apr 24, 2015 at 3:04 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: > > I think what we need here is something that does heap_update to tuples > > at the end of the table, moving them to earlier pages; then wait for old > > snapshots to die (the infrastructure for which we have now, thanks to > > CREATE INDEX CONCURRENTLY); then truncate the empty pages. Of course, > > there are lots of details to resolve. It doesn't really matter that > > this runs for long: a process doing this for hours might be better than > > AccessExclusiveLock on the table for a much shorter period. > > Why do you need to do anything other than update the tuples and let > autovacuum clean up the mess? Sure, that's one option. I think autovac's current approach is too heavyweight: it always has to scan the whole relation and all the indexes. It might be more convenient to do something more fine-grained; for instance, maybe instead of scanning the whole relation, start from the end of the relation walking backwards and stop once the first page containing a live or recently-dead tuple is found. Perhaps, while scanning the indexes you know that all CTIDs with pages higher than some threshold value are gone; you can remove them without scanning the heap at all perhaps. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: