From: | legrand legrand <legrand_legrand(at)hotmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Planning counters in pg_stat_statements (using pgss_store) |
Date: | 2020-04-02 20:04:28 |
Message-ID: | 1585857868967-0.post@n3.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
>
> Regards,
>
> --
> Fujii Masao
> Advanced Computing Technology Center
> Research and Development Headquarters
> NTT DATA CORPORATION
Thank you all for this work and especially to Julian for its major
contribution !
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."
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2020-04-02 20:34:26 | Re: backup manifests |
Previous Message | Peter Geoghegan | 2020-04-02 20:04:12 | Re: snapshot too old issues, first around wraparound and then more. |