Re: Planning counters in pg_stat_statements (using pgss_store)

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Planning counters in pg_stat_statements (using pgss_store)
Дата
Msg-id CAOBaU_YKtC78KmEc_W98yz=BGKd3Lgx-q7D37_sTA9VdsW+xOQ@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Planning counters in pg_stat_statements (using pgss_store)  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
Ответы RE: Planning counters in pg_stat_statements (using pgss_store)  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
Список pgsql-hackers
On Fri, Nov 15, 2019 at 2:00 AM imai.yoshikazu@fujitsu.com
<imai.yoshikazu@fujitsu.com> wrote:
>
> Actually I also don't have strong opinion but I thought someone would complain about renaming of those columns and
alsosome tools like monitoring which use those columns will not work. If we use {total, min, max, mean, stddev}_time,
someonemight mistakenly understand {total, min, max, mean, stddev}_time mean {total, min, max, mean, stddev} of
planningand execution. 
> If I need to choose {total, min, max, mean, stddev}_time or {total, min, max, mean, stddev}_exec_time, I choose
formerone because choosing best name is not worth destructing the existing scripts or tools. 

We could definitely keep (plan|exec)_time for the SRF, and have the
{total, min, max, mean, stddev}_time created by the view to be a sum
of planning + execution for each counter, and it doesn't sound like a
bad idea if having even more columns in the view is not an issue.



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

Предыдущее
От: Jeremy Finzel
Дата:
Сообщение: Re: physical slot xmin dependency on logical slot?
Следующее
От: vignesh C
Дата:
Сообщение: initdb SegFault