Re: [HACKERS] Planning counters in pg_stat_statements

Hi,

Is anybody still working on this? Are there any plans to add this to 
commitfest?

I'd like to add planning time to auto_explain, and it turns out that 
this patch is somewhat relevant to that feature.

The current approach here is to set planning_time in PlannedStmt via 
planner_hook, which (in my opinion) has several flaws:

1. Depending on the order of extensions in shared_preload_libraries, it 
might not measure time spent on preceding planner hooks.

2. Provided that there are multiple users of this metric, it might 
become a little too costy to register several hooks with identical 
purpose.

3. [Bikeshedding] Although planning time is stored in PlannedStmt, it's 
definitely not an inherent property of a plan. You could have two 
machines with identical settings but quite different planning times due 
to various circumstances (raw CPU power, I/O etc).

I'd argue that it might be better to add a new argument to 
pg_plan_query() and pg_plan_queries() and a new field to QueryDesc, 
i.e.:

PlannedStmt *
pg_plan_query(Query *querytree,
              int cursorOptions,
              ParamListInfo boundParams,
              double *planningTime)

List *
pg_plan_queries(List *querytrees,
                int cursorOptions,
                ParamListInfo boundParams,
                double *planningTime) /* total time as in BuildCachedPlan() */

The measured time can later be passed to QueryDesc via 
PortalDefineQuery(). Of course, this requires more changes, but the 
result might be worth it.

What do you think?

--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company