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