Re: Idea for getting rid of VACUUM FREEZE on cold pages
От | Robert Haas |
---|---|
Тема | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Дата | |
Msg-id | AANLkTimINO9iAhvPboj2F5iVzSYS0k1h5DEmusSZx3Vb@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Idea for getting rid of VACUUM FREEZE on cold pages (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Idea for getting rid of VACUUM FREEZE on cold pages
|
Список | pgsql-hackers |
On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@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
В списке pgsql-hackers по дате отправления: