[legrand legrand <legrand_legrand@hotmail.com>]

Hello,

This is a call for committers, reviewers and users,
regarding "planning counters in pg_stat_statements"
patch [1] but not only.

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():
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.

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.

note:
A problem was discovered during IVM testing,
because some queries without sql text where planned
without being parsed, finishing in pgss with a zero 
queryid.

A work arround is to set track_planning = false,
we have chosen to fix that in pgss by ignoring
zero queryid inside pgss_planner_hook.

Thanks in advance
Regards
PAscal
  
[1] " https://www.postgresql.org/message-id/20200309103142.GA45401%40nol
<planning counters in pg_stat_statements>  "



--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html