Re: Is it useful to record whether plans are generic or custom?
От | torikoshia |
---|---|
Тема | Re: Is it useful to record whether plans are generic or custom? |
Дата | |
Msg-id | 12e8d4a87f94d6dd523da5528c50c618@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Is it useful to record whether plans are generic or custom? (torikoshia <torikoshia@oss.nttdata.com>) |
Ответы |
Re: Is it useful to record whether plans are generic or custom?
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: