Re: Idea for getting rid of VACUUM FREEZE on cold pages

On 22/05/10 16:35, Tom Lane wrote:
> Josh Berkus<josh@agliodbs.com>  writes:
>>    From a discussion at dinner at pgcon, I wanted to send this to the list
>> for people to poke holes in it:
>
> Somebody (I think Joe or Heikki) poked a big hole in this last night at
> the Royal Oak.

Me.

>  Although the scheme would get rid of the need to replace
> old XIDs with FrozenXid, it does not get rid of the need to set hint
> bits before you can truncate CLOG.

Hmm, we don't rely on setting hint bits to truncate CLOG anymore 
(http://archives.postgresql.org/pgsql-committers/2006-11/msg00026.php). 
It's the replacement of xids with FrozenXid that matters, the hint bits 
are really just hints.

Doesn't change the conclusion, though: you still need to replace XIDs 
with FrozenXids to truncate the clog. Conceivably we could keep around 
more than 2^32 transactions in clog with this scheme, but then you need 
a lot more space for the clog. But perhaps it would be better to do that 
than to launch anti-wraparound vacuums, or to refuse more updates in the 
extreme cases.

>  So in your example of an insert-only
> table that's probably never read again, there's still a minimum of one
> update visit required on every old page.  Now that's still better than
> two update visits ... but we could manage that already, just by tweaking
> vacuum's heuristics about when to freeze vs when to set hint bits.

(As also discussed in the Royal Oak) I think we should simply not dirty 
a page when a hint bit is updated. Reading a page from disk is 
expensive, setting hint bits on the access is generally cheap compared 
to that. But that is orthogonal to the idea of a per-page XID epoch.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com