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