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