Re: Wait events monitoring future development

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Wait events monitoring future development
Дата
Msg-id CAMsr+YEZkNTAe9K_5rd8EVkTHUjnvUcxqsz=LSp_ncv-fabE9A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Wait events monitoring future development  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On 10 August 2016 at 07:09, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
 
 
The downside to leaving stuff like this off by default is users won't remember it's there when they need it. At best, that means they spend more time debugging something than they need to. At worse, it means they suffer a production outage for longer than they need to, and that can easily exceed many months/years worth of the extra cost from the monitoring overhead.

Yeah.. and I've got to say, the whole "it'll hurt benchmarks if it's on by default" argument falls flat on its face when you look at our defaults for shared_buffers, etc.
 
If you don't tune Pg, it runs reliably, but slowly. If this proves to have "reasonable" overhead, I'd be inclined to say it should just be on. I frequently wish auto_explain and pg_stat_statements were in-core and on-by-default so when someone calls saying things got slow the historical data is already there. I'm sure this'll be the same.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: [sqlsmith] Failed assertion in joinrels.c
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: PATCH: Batch/pipelining support for libpq