On 2020/03/10 6:31, legrand legrand wrote:
> Hello,
>
> This is a call for committers, reviewers and users,
> regarding "planning counters in pg_stat_statements"
> patch [1] but not only.
Does anyone object to this patch? I'm thinking to commit it separetely
at first before committing the planning_counter_in_pg_stat_statements
patch.
> Historically, this version of pg_stat_statements
> with planning counters was performing 3 calls to
> pgss_store() for non utility statements in:
> 1 - pgss_post_parse_analyze (init entry with queryid
> and store query text)
> 2 - pgss_planner_hook (to store planning counters)
> 3 - pgss_ExecutorEnd (to store execution counters)
>
> Then a new version was proposed to remove one call
> to pgss_store() by adding the query string to the
> planner pg_plan_query():
But pgss_store() still needs to be called three times even in
non-utility command if the query has constants. Right?
> 1 - pgss_planner_hook (to store planning counters)
> 2 - pgss_ExecutorEnd (to store execution counters)
>
> Many performances tests where performed concluding
> that there is no impact on this subject.
Sounds good!
> Patch "to pass query string to the planner", could be
> committed by itself, and (maybe) used by other extensions.
>
> If this was done, this new version of pgss with planning
> counters could be committed as well, or even later
> (being used as a non core extension starting with pg13).
>
> So please give us your feedback regarding this patch
> "to pass query string to the planner", if you have other
> use cases, or any comment regarding core architecture.
*As far as I heard*, pg_hint_plan extension uses very tricky way to
extract query string in the planner hook. So this patch would be
very helpful to make pg_hint_plan avoid using such tricky way.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
