Re: Planning counters in pg_stat_statements (using pgss_store)

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Planning counters in pg_stat_statements (using pgss_store)
Дата
Msg-id 20200320193004.rqgf3iim4fugq3sm@nol
обсуждение исходный текст
Ответ на Re: Planning counters in pg_stat_statements (using pgss_store)  (Sergei Kornilov <sk@zsrv.org>)
Ответы Re: Planning counters in pg_stat_statements (using pgss_store)  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote:
> Hello
> 
> Yet another is missed in docs: total_time

Oh good catch!  I rechecked many time the field, and totally missed that the
documentation is referring to the view, which has an additional column, and not
the function.  Attached v9 fixes that.

> I specifically verified that the new loaded library works with the old version of the extension in the database. I
havenot noticed issues here.
 

Thanks for those extra checks.

> > 2.2% is a bit large but I think it is still acceptable because people using this feature
> > might take account that some overhead will happen for additional calling of a
> > gettime function.
> 
> I will be happy even with 10% overhead due to enabled track_planning... (but in this case disabled by default)
log_min_duration_statement= 0 with log parsing is much more expensive.
 
> I think 1-2% is acceptable and we can set track_planning = on by default as patch does.
> 
> > * Rows for executor time are changed from {total/min/max/mean/stddev}_time to
{total/min/max/mean/stddev}_exec_time.
> 
> Maybe release it as 2.0 version instead of minor update 1.18?

I don't have an opinion on that, I'd be fine with any version.  I kept 1.18 in
the patch for now.

Вложения

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

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: Add A Glossary
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: SQL/JSON: functions