Re: pg_stat_statements and planning time

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pg_stat_statements and planning time
Дата
Msg-id CAEYLb_WSr0eo+vOTcT7LikMfvc3p-x-BNRLFLj-tNJVuTGJBdA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_statements and planning time  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 8 March 2012 14:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

To be clear, I don't see any reasons to not just have it within
EXPLAIN output under all circumstances.

pg_stat_statements will slow down query execution, but I see no reason
to force users to pay for something that they may well not want by not
including an 'off' switch for this additional instrumentation, given
that it doubles the number of gettimeofdays. I'm not particularly
concerned about platforms with slow gettimeofdays. I'm concerned with
keeping the overhead of running pg_stat_statements as low as possible
generally.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Collect frequency statistics for arrays
Следующее
От: Marti Raudsepp
Дата:
Сообщение: [PATCH] Optimize IS DISTINCT FROM NULL => IS NOT NULL