Re: Set visibility map bit after HOT prune

Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Seems unlikely to be a win. We only care about freezing tuples in the
>> context of being able to advance a relation-wide relfrozenxid horizon.
>> Freezing pages retail accomplishes nothing whatsoever towards that goal,
>> unless you have some way to know that no new freeze work will be needed
>> on the page before the next vacuum freeze happens. Otherwise, you're
>> just moving portions of the work from background vacuuming into
>> foreground processes, with no benefit gained thereby.

> If we can establish an invariant that a all-visible page is always
> fully freezed, then vacuum freeze does not need to look at those pages
> again.

We're not going to do that, because it would require freezing tuples
immediately after they fall below the RecentGlobalXmin horizon. This
would be a significant loss of capability from a forensic standpoint,
not to mention breaking existing applications that look at xmin to
determine whether a tuple has recently been updated. Besides which,
I think it would result in a large increase in the WAL volume emitted
by prune operations (hint bit setting doesn't require WAL, unlike
freezing). I don't believe for a minute your argument that it would
result in a net reduction in WAL.

regards, tom lane