Re: Is it useful to record whether plans are generic or custom?
torikoshia <torikoshia@oss.nttdata.com>
From: torikoshia <torikoshia@oss.nttdata.com>
To: pgsql-hackers@postgresql.org
Cc: "Fujii Masao <masao.fujii@oss.nttdata.com>Kyotaro Horiguchi"
<horikyota.ntt@gmail.com>, ikedamsh@oss.nttdata.com, atorik@gmail.com,
legrand_legrand@hotmail.com, tatsuro.yamada.tf@nttcom.co.jp
Date: 2020-07-22T07:49:53Z
Lists: pgsql-hackers
Attachments
- 0001-POC-add-plan-type-to-pgss.patch (text/x-diff) patch 0001
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
Commits
-
Add generic_plans and custom_plans fields into pg_prepared_statements.
- d05b172a760e 14.0 landed