From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Heikki <hlinnaka(at)iki(dot)fi> |
Subject: | Re: Feedback on getting rid of VACUUM FULL |
Date: | 2015-04-28 18:44:24 |
Message-ID: | 20150428184424.GD4369@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Fri, Apr 24, 2015 at 3:04 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-04-28 19:35:39 | COPY and file_fdw with fixed column widths |
Previous Message | Robert Haas | 2015-04-28 18:40:04 | Re: parallel mode and parallel contexts |