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)
|
Список | 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 по дате отправления: