"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> 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.)
Well there were three suggestions on how to track whether the last vacuum
committed or not. Keeping the last vacuum id in pg_class, keeping it per-page,
and keeping it per line pointer. ISTM either of the latter two would work with
partial table vacuums. Per line-pointer xids seemed excessively complicated to
me but per-page vacuum ids doesn't seem problematic.
I would definitely agree that partial-table vacuums are an essential part of
the future.
>> 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.
Well I'm not pretending. I guess there's something I'm missing here. I thought
we only pruned when we wanted to insert a new tuple and found not enough
space.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
