Idea for getting rid of VACUUM FREEZE on cold pages
in [PgSql]
|
Prev: [HACKERS] beta testing - planner bug - ERROR: XX000: failed to build any 2-way joins
Next: [HACKERS] beta testing - pg_upgrade bug fix - double free
From: Alvaro Herrera on 25 May 2010 13:10 Excerpts from Heikki Linnakangas's message of mar may 25 04:41:30 -0400 2010: > On 24/05/10 22:49, Alvaro Herrera wrote: > > I think this is nonsense. If you have 3-years-old sales transactions, > > and your database has any interesting churn, tuples those pages have > > been frozen for a very long time *already*. > What's missing from the suggestion is that relfrozenxid and datfrozenxid > also need to be expanded to 8-bytes. That way you effectively have > 8-byte XIDs, which means that you never need to vacuum to avoid XID > wraparound. Hmm, so are we going to use the "xid epoch" more officially? That's entirely a new line of development, perhaps it opens new possibilities. This sounds like extending Xid to 64 bits, without having to store the high bits everywhere. Was this discussed in the PGCon devs meeting? -- Álvaro Herrera <alvherre(a)alvh.no-ip.org> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 25 May 2010 14:16 Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes: > This sounds like extending Xid to 64 bits, without having to store the > high bits everywhere. Was this discussed in the PGCon devs meeting? Yeah, that's what it would amount to. It was not discussed at the dev meeting --- it was an idea that came up one evening at PGCon. I'm not sure whether this would imply having to widen xid to 64 bits internally. That could be a bit unpleasant as far as CPU and shared memory space go, although every year that goes by makes 32-bit machines less interesting as DB servers. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 25 May 2010 16:49 Alvaro, >> This sounds like extending Xid to 64 bits, without having to store the >> high bits everywhere. Was this discussed in the PGCon devs meeting? Essentially, yes. One of the main objections to raising XID to 64-bit has been the per-row overhead. But adding 4 bytes per page wouldn't be much of an impact. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jan Wieck on 25 May 2010 16:53 On 5/24/2010 9:30 AM, Heikki Linnakangas wrote: > On 22/05/10 16:35, Tom Lane wrote: >> Josh Berkus<josh(a)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. Correct. The problem actually are aborted transactions. Just because an XID is really old doesn't mean it was committed. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 25 May 2010 16:56
> Correct. The problem actually are aborted transactions. Just because an > XID is really old doesn't mean it was committed. Yes, that's the main issue with my idea; XIDs which fell off the CLOG would become visible even if they'd aborted. Do we get a bit in the visibility map for a page which has aborted transaction rows on it? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |