Re: Patch: to pass query string to pg_plan_query()

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