Re: Planning counters in pg_stat_statements (using pgss_store)

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: "imai(dot)yoshikazu(at)fujitsu(dot)com" <imai(dot)yoshikazu(at)fujitsu(dot)com>
Cc: "tomas(dot)vondra(at)2ndquadrant(dot)com" <tomas(dot)vondra(at)2ndquadrant(dot)com>, legrand legrand <legrand_legrand(at)hotmail(dot)com>, "sk(at)zsrv(dot)org" <sk(at)zsrv(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Imai Yoshikazu <yoshikazu_i443(at)live(dot)jp>
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)
Date: 2020-01-05 08:53:43
Message-ID: CAOBaU_bKDoMxEWLqJue8ZS-kamcwKS2zUROONjEtp_sHmbBegg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 22, 2019 at 11:23 AM imai(dot)yoshikazu(at)fujitsu(dot)com
<imai(dot)yoshikazu(at)fujitsu(dot)com> wrote:
>
> On Wed, Nov 20, 2019 at 4:55 PM, Julien Rouhaud wrote:
> > 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.
>
> Ah, I see. Planning counts and execution counts differ.
> It might be difficult to redefine the meaning of {min, max, mean, stddev}_time precisely, and even if we can redefine it correctly, it would not be intuitive.

Thomas' automatic patch tester just warned me that the patchset is
broken since 3fd40b628c7db4, which removed the queryString from
ExecCreateTableAs. New patch version that re-add the queryString, no
changes otherwise.

Attachment Content-Type Size
0001-Pass-query-string-to-the-planner-v3.patch application/octet-stream 11.9 KB
0002-Add-planning-counters-to-pg_stat_statements-v3.patch application/octet-stream 45.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2020-01-05 09:02:29 Re: pgbench - add pseudo-random permutation function
Previous Message Andrey Lepikhov 2020-01-05 06:11:19 Re: NOT IN subquery optimization