Re: Freezing tuples on pages dirtied by vacuum - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Freezing tuples on pages dirtied by vacuum
Date
Msg-id 22090.1153490613@sss.pgh.pa.us
Whole thread Raw
In response to Re: Freezing tuples on pages dirtied by vacuum  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Freezing tuples on pages dirtied by vacuum  (Jim Nasby <jnasby@pervasive.com>)
List pgsql-hackers
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> For clobbering xmin too early, we could make it so that only tuples
> older than some threashold would be subject to 'early freezing'.

OK, that might be acceptable.

> 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).

No, the freeze-at-1B rule is the maximum safe delay.  Read the docs.
But we could do early freeze at 0.5B and forced freeze at 1B and
probably still get the effect you want.

However, I remain unconvinced that this is a good idea.  You'll be
adding very real cycles to regular vacuum processing (to re-scan tuples
already examined) in hopes of obtaining a later savings that is really
pretty hypothetical.  Where is your evidence that writes caused solely
by tuple freezing are a performance issue?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [PATCHES] 8.2 features?