Re: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Nov 20, 2019 at 2:06 AM imai(dot)yoshikazu(at)fujitsu(dot)com
<imai(dot)yoshikazu(at)fujitsu(dot)com> wrote:
>
> On Tue, Nov 19, 2019 at 2:27 PM, Julien Rouhaud wrote:
> > On Fri, Nov 15, 2019 at 2:00 AM imai(dot)yoshikazu(at)fujitsu(dot)com <imai(dot)yoshikazu(at)fujitsu(dot)com> wrote:
> > >
> > > Actually I also don't have strong opinion but I thought someone would complain about renaming of those columns and
> > also some tools like monitoring which use those columns will not work. If we use {total, min, max, mean, stddev}_time,
> > someone might mistakenly understand {total, min, max, mean, stddev}_time mean {total, min, max, mean, stddev} of planning
> > and execution.
> > > If I need to choose {total, min, max, mean, stddev}_time or {total, min, max, mean, stddev}_exec_time, I choose former
> > one 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
>
> I might misunderstand but if we define {total, min, max, mean, stddev}_time is
> just a sum of planning + execution for each counter like
> "select total_plan_time + total_exec_time as total_time from pg_stat_statements",
> I wonder we can calculate stddev_time correctly. If we prepare variables in
> the codes to calculate those values, yes, we can correctly calculate those
> values even for the total_stddev.

Yes you're right, this can't possibly work for most of the counters.
And also, since there's no guarantee that each execution will follow a
planning, providing such global counters for min/max/mean and stddev
wouldn't make much sense.