Re: [PATCHES] VACUUM Improvements - WIP Patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] VACUUM Improvements - WIP Patch
Date
Msg-id 28739.1216058100@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] VACUUM Improvements - WIP Patch  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: [PATCHES] VACUUM Improvements - WIP Patch  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> I like the idea of only having to do a single pass through the table though.

Well, that argument was already overstated: we're not re-reading all of
the table now.  Just the pages containing dead line pointers.

> Couldn't Pavan's original plan still work and just not have other clients try
> to remove dead line pointers?

You could simply delay recycling of the really-truly-dead line pointers
until the next VACUUM, I suppose.  It's not clear how bad a
line-pointer-bloat problem that might leave you with.  (It would still
require tracking whether the last vacuum had completed successfully.
I note that any simple approach to that would foreclose ever doing
partial-table vacuums, which is something I thought was on the table
as soon as we had dead space mapping ability.)

> At least not unless they're also pruning the
> page due to an insert or update anyways?

Please stop pretending that this overhead will only be paid by
insert/update.  The current design for pruning does not work that way,
and we do not have a better design available.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: testing locales and encodings
Next
From: Andrew Dunstan
Date:
Subject: Re: PATCH: CITEXT 2.0 v3