Re: Planning counters in pg_stat_statements (using pgss_store) - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Planning counters in pg_stat_statements (using pgss_store)
Date
Msg-id CAOBaU_YKtC78KmEc_W98yz=BGKd3Lgx-q7D37_sTA9VdsW+xOQ@mail.gmail.com
Whole thread Raw
In response to RE: Planning counters in pg_stat_statements (using pgss_store)  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
Responses RE: Planning counters in pg_stat_statements (using pgss_store)  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
List 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 by date:

Previous
From: Jeremy Finzel
Date:
Subject: Re: physical slot xmin dependency on logical slot?
Next
From: vignesh C
Date:
Subject: initdb SegFault