On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers