On Wed, Nov 20, 2019 at 2:06 AM imai.yoshik...@fujitsu.com
<imai.yoshik...@fujitsu.com> wrote:
>
> On Tue, Nov 19, 2019 at 2:27 PM, Julien Rouhaud wrote:
> > On Fri, Nov 15, 2019 at 2:00 AM imai.yoshik...@fujitsu.com
> > <imai.yoshik...@fujitsu.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.
