On Wed, Nov 20, 2019 at 2:06 AM imai.yoshikazu@fujitsu.com
<imai.yoshikazu@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.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
> > 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.
