Pavan Deolasee <pavan.deola...@gmail.com> writes:
> On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
