On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
Excerpts from Robert Haas's message of mié jun 02 14:16:33 -0400 2010:
We could, but I think we'd be better off just freezing at the time we
mark the page PD_ALL_VISIBLE and then using the visibility map for
both purposes. Keeping around the old xmin values after every tuple
on the page is visible to every running transaction is useful only for
forensics, and building a whole new freeze map just to retain that
information longer (and eventually force a massive anti-wraparound
vacuum) seems like overkill.
Reducing the xid wraparound horizon "a bit" is reasonable, but moving it
all the way forward to OldestXmin is a bit much, methinks.
Why?
Besides, there's another argument for not freezing tuples immediately:
they may be updated shortly thereafter, causing extra churn for no gain.
What extra churn does it create if the tuple can be frozen before the
bgwriter ever writes the page in the first place?
I'd prefer a setting that would tell the system to freeze all tuples
that fall within a safety range whenever any tuple in the page is frozen
-- weren't you working on a patch to do this? (was it Jeff Davis?)
I just see a lot of cost caused by this "safety range". I yet have to
see its real value, other than "feel good".
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
