Re: Is it useful to record whether plans are generic or custom? - Mailing list pgsql-hackers

From torikoshia
Subject Re: Is it useful to record whether plans are generic or custom?
Date
Msg-id 12e8d4a87f94d6dd523da5528c50c618@oss.nttdata.com
Whole thread Raw
In response to Re: Is it useful to record whether plans are generic or custom?  (torikoshia <torikoshia@oss.nttdata.com>)
Responses Re: Is it useful to record whether plans are generic or custom?
List pgsql-hackers
On 2020-07-20 13:57, torikoshia wrote:

> As I proposed earlier in this thread, I'm now trying to add information
> about generic/cudstom plan to pg_stat_statements.
> I'll share the idea and the poc patch soon.

Attached a poc patch.

Main purpose is to decide (1) the user interface and (2) the
way to get the plan type from pg_stat_statements.

(1) the user interface
I added a new boolean column 'generic_plan' to both
pg_stat_statements view and the member of the hash key of
pg_stat_statements.

This is because as Legrand pointed out the feature seems
useful under the condition of differentiating all the
counters for a queryid using a generic plan and the one
using a custom one.

I thought it might be preferable to make a GUC to enable
or disable this feature, but changing the hash key makes
it harder.

(2) way to get the plan type from pg_stat_statements
To know whether the plan is generic or not, I added a
member to CachedPlan and get it in the ExecutorStart_hook
from ActivePortal.
I wished to do it in the ExecutorEnd_hook, but the
ActivePortal is not available on executorEnd, so I keep
it on a global variable newly defined in pg_stat_statements.


Any thoughts?

This is a poc patch and I'm going to do below things later:

- update pg_stat_statements version
- change default value for the newly added parameter in
   pg_stat_statements_reset() from -1 to 0(since default for
   other parameters are all 0)
- add regression tests and update docs



Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2
Next
From: Georgios
Date:
Subject: Re: Using Valgrind to detect faulty buffer accesses (no pin or buffer content lock held)