Re: Planning counters in pg_stat_statements (using pgss_store)

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: legrand legrand <legrand_legrand(at)hotmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)
Date: 2020-04-03 07:26:28
Message-ID: 20200403072628.GB95652@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 02, 2020 at 01:04:28PM -0700, legrand legrand wrote:
> Fujii Masao-4 wrote
> > On 2020/04/01 18:19, Fujii Masao wrote:
> >
> > Finally I pushed the patch!
> > Many thanks for all involved in this patch!
> >
> > As a remaining TODO item, I'm thinking that the document would need to
> > be improved. For example, previously the query was not stored in pgss
> > when it failed. But, in v13, if pgss_planning is enabled, such a query is
> > stored because the planning succeeds. Without the explanation about
> > that behavior in the document, I'm afraid that users will get confused.
> > Thought?
>
> Thank you all for this work and especially to Julian for its major
> contribution !

Thanks a lot to everyone! This was quite a long journey.

> Regarding the TODO point: Yes I agree that it can be improved.
> My proposal:
>
> "Note that planning and execution statistics are updated only at their
> respective end phase, and only for successfull operations.
> For exemple executions counters of a long running SELECT query,
> will be updated at the execution end, without showing any progress
> report in the interval.
> Other exemple, if the statement is successfully planned but fails in
> the execution phase, only its planning statistics are stored.
> This may give uncorrelated plans vs calls informations."

There are numerous reasons for lack of correlation between number of planning
and number of execution, so I'm afraid that this will give users the false
impression that only failed execution can lead to that.

Here's some enhancement on your proposal:

"Note that planning and execution statistics are updated only at their
respective end phase, and only for successful operations.
For example the execution counters of a long running query
will only be updated at the execution end, without showing any progress
report before that.
Similarly, if a statement is successfully planned but fails during
the execution phase, only its planning statistics will be displayed.
Please also note that the number of planning and number of execution aren't
expected to match, as the planification of a query won't always be followed by
its execution and reciprocally."

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2020-04-03 07:42:57 Re: Binary support for pgoutput plugin
Previous Message David G. Johnston 2020-04-03 07:05:58 Re: Syntax rules for a text value inside the literal for a user-defined type—doc section “8.16.2. Constructing Composite Values”