Re: pg_stat_statements and planning time

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_stat_statements and planning time
Дата
Msg-id 10436.1331217846@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_stat_statements and planning time  (Peter Geoghegan <peter@2ndquadrant.com>)
Ответы Re: pg_stat_statements and planning time
Список pgsql-hackers
Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 8 March 2012 13:09, Robert Haas <robertmhaas@gmail.com> wrote:
>> �Then again, considering that gettimeofday is kinda
>> expensive, I suppose that would have to be optional if we were to have
>> it at all.

> +1. I'm not opposed to having such a mechanism, but it really ought to
> impose exactly no overhead on the common case where we don't
> particularly care about plan time.

I thought the proposal was to add it to (1) pg_stat_statement and (2)
EXPLAIN, both of which are not in the normal code execution path.
pg_stat_statement is already a drag on a machine with slow gettimeofday,
but it's not clear why users of it would think that two gettimeofday's
per query are acceptable and four are not.
        regards, tom lane


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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Finer Extension dependencies
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade --logfile option documentation