"Tom Lane" <tgl@sss.pgh.pa.us> writes:
>>> It strikes me that what you are trying to do here is compensate for
>>> a bad decision in the HOT patch, which was to have VACUUM's first
>>> pass prune/defrag a page even when we know we are going to have to
>>> come back to that page later. What about trying to fix things so
>>> that if the page contains line pointers that need to be removed,
>>> the first pass doesn't dirty it at all, but leaves all the work
>>> to be done at the second visit?
>
>> I am not against this idea. Just that it still requires us double scan
>> of the main table and that's exactly what we are trying to avoid with
>> this patch.
>
> The part of the argument that I found convincing was trying to reduce
> the write traffic (especially WAL log output), not avoiding a second
> read. And the fundamental point still remains: the work should be done
> in background, not foreground.
I like the idea of only having to do a single pass through the table though.
Couldn't Pavan's original plan still work and just not have other clients try
to remove dead line pointers? At least not unless they're also pruning the
page due to an insert or update anyways?
Fundamentally it does seem like we want to rotate vacuum's work-load. What
we're doing now is kind of backwards.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
