Re: RFC: replace pg_stat_activity.waiting with something more descriptive

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id 5285.1436883910@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>)
Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I really think we should do the simple thing first.  If we make this
> complicated and add lots of bells and whistles, it is going to be much
> harder to get anything committed, because there will be more things
> for somebody to object to.  If we start with something simple, we can
> always improve it later, if we are confident that the design for
> improving it is good.  The hardest thing about a proposal like this is
> going to be getting down the overhead to a level that is acceptable,
> and every expansion of the basic design that has been proposed -
> gathering more than one byte of information, or gathering times, or
> having the backend update a tracking hash - adds *significant*
> overhead to the design I proposed.

FWIW, I entirely share Robert's opinion that adding gettimeofday()
overhead in routinely-taken paths is likely not to be acceptable.
But there's no need to base this solely on opinions.  I suggest somebody
try instrumenting just one hotspot in the various ways that are being
proposed, and then we can actually measure what it costs, instead
of guessing about that.
        regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: multivariate statistics / patch v7
Следующее
От: Tom Lane
Дата:
Сообщение: Re: TABLESAMPLE patch is really in pretty sad shape