Re: Freezing tuples on pages dirtied by vacuum

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Freezing tuples on pages dirtied by vacuum
Date: 2006-07-21 14:03:33
Message-ID: 22090.1153490613@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim C. Nasby" <jnasby(at)pervasive(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-07-21 14:08:32 Re: [PATCHES] 8.2 features?
Previous Message Jim C. Nasby 2006-07-21 13:56:53 Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL