On Wed, Apr 08, 2020 at 05:37:27PM +0900, Fujii Masao wrote: > > > On 2020/04/03 16:26, Julien Rouhaud wrote: > > 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." > > Thanks for the proposal! > > > 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. > > Probably since this is not the example for explaining the relationship of > planning and execution stats, it's better to explain this separately or just > drop it? > > What about the attached patch based on your proposals? >
Thanks Fuji-san, it looks perfect to me!
