Re: [HACKERS] Planning counters in pg_stat_statements - Mailing list pgsql-hackers

From Dmitry Ivanov
Subject Re: [HACKERS] Planning counters in pg_stat_statements
Date
Msg-id 591949adc675a141062b139d3ee75457@postgrespro.ru
Whole thread Raw
In response to Re: [HACKERS] Planning counters in pg_stat_statements  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] Planning counters in pg_stat_statements  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: libpq compression
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] asynchronous execution