Re: Freezing tuples on pages dirtied by vacuum

On Wed, Jul 19, 2006 at 07:45:24PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > ISTM that as soon as vacuum dirties a page, it might as well update all
> > tuples it can (any where Xmin < GetOldestXmin()), since that won't take
> > much time compared to the cost of writing the page out.
>
> Perhaps not, but what it will do is destroy data that you might wish you
> had later. Check the archives and note how often we ask people for xmin
> values when trying to debug a problem. I don't think it's a good idea
> for aggressive freezing of tuples to be the default behavior. Moreover,
> I can't see that there'd be any real gain from having done it --- it
> doesn't look to me like it would save any vacuum-to-prevent-wraparound
> operations, since nothing would happen at non-dirty pages.

For any tables that see even a trivial rate of updates spread through
the table, odds are that all tuples will end up frozen well before 1B
transactions have passed. Yes, you'll still need to vacuum every 1B
transactions, but that vacuum wouldn't need to dirty any pages just to
freeze tuples.

For clobbering xmin too early, we could make it so that only tuples
older than some threashold would be subject to 'early freezing'. One
possibility is that early freeze is at 1B transactions and we push
forced-freeze back to 1.5B transactions (the current forced-freeze at 1B
transactions seems rather aggresive anyway, now that the server will
refuse to issue new commands rather than lose data due to wraparound).

BTW, the freeze limits for vacuum and autovac are currently defined in
different places; should I submit a patch to refactor that into one
place? (Presumably vacuum.c)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461