On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
>> Ok. Will try to read archives to see what was actually suggested and
>> why it was put on back burner. BTW at the risk of being shot down
>> again, I wonder if can we push down the freeze operation to HOT prune
>> also.
>
> 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. Another advantage is that we are holding the right lock and
piggyback freeze with cleanup WAL-logging, thus avoiding re-dirtying
of the page and additional WAL logging.
> In fact, you
> might well be *creating* work that would otherwise not have had to be
> done at all --- the tuple might get deleted before the next freeze
> happens.
>
Yeah, there will be cases where it might not add any value or even add
little overhead. Don't know what will serve better on an average or
majority of the workloads though. Vacuum freeze has known to add
sudden and unexpected load on the system, so I thought this might
mitigate that to a certain extent.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
