On 22/05/10 16:35, Tom Lane wrote:
Josh Berkus<j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
