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: Jan Wieck on 4 Jun 2010 08:01 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 4 Jun 2010 11:13 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Jan Wieck <JanWieck(a)Yahoo.com> writes: >> 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, you don't know what you're talking about. I have repeatedly > had cases where being able to look at xmin was critical to > understanding a bug. I *will not* hold still for a solution that > effectively reduces min_freeze_age to zero. In my experience with my own environment, I can honestly say that it's clear that not freezing tuples quickly adds more cost than running with cassert on. If we had to run in production with one or the other, I would definitely choose cassert from a performance perspective; which one would do more to find bugs? Why do we view them so differently? -Kevin -- 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 4 Jun 2010 11:45 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > In my experience with my own environment, I can honestly say that > it's clear that not freezing tuples quickly adds more cost than > running with cassert on. If we had to run in production with one or > the other, I would definitely choose cassert from a performance > perspective; which one would do more to find bugs? Why do we view > them so differently? The reason for not recommending cassert in production builds is not cost but stability. Per the fine manual: Also, having the tests turned on won't necessarily enhance the stability of your server! The assertion checks are not categorized for severity, and so what might be a relatively harmless bug will still lead to server restarts if it triggers an assertion failure. This option is not recommended for production use, but you should have it on for development work or when running a beta version. 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: Robert Haas on 4 Jun 2010 11:49 On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: >> In my experience with my own environment, I can honestly say that >> it's clear that not freezing tuples quickly adds more cost than >> running with cassert on. If we had to run in production with one or >> the other, I would definitely choose cassert from a performance >> perspective; which one would do more to find bugs? Why do we view >> them so differently? > > The reason for not recommending cassert in production builds is not > cost but stability. Per the fine manual: > > Also, having the tests turned on won't necessarily enhance the > stability of your server! The assertion checks are not categorized > for severity, and so what might be a relatively harmless bug will > still lead to server restarts if it triggers an assertion > failure. This option is not recommended for production use, but > you should have it on for development work or when running a beta > version. We routinely castigate people for benchmarking done with cassert turned on, and tell them their numbers are meaningless. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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 4 Jun 2010 11:59
Robert Haas <robertmhaas(a)gmail.com> writes: > On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> The reason for not recommending cassert in production builds is not >> cost but stability. > We routinely castigate people for benchmarking done with cassert > turned on, and tell them their numbers are meaningless. I didn't say it wasn't expensive ;-). But Kevin's question seemed to be based on the assumption that runtime cost was the only negative. It wouldn't be terribly hard to make a variant of cassert that skips two or three of the most expensive things (particularly memory context checking and CLOBBER_FREED_MEMORY), and from a cost perspective that would be totally reasonable to run in production. We haven't done it because of the stability issue. 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 |