Re: track generic and custom plans in pg_stat_statements
| От | Sami Imseih |
|---|---|
| Тема | Re: track generic and custom plans in pg_stat_statements |
| Дата | |
| Msg-id | CAA5RZ0s=K+CvM6dZcYnvzitsU0g7btDjRpVjOU8PAh8PP=zX5w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: track generic and custom plans in pg_stat_statements (Andrei Lepikhov <lepihov@gmail.com>) |
| Ответы |
Re: track generic and custom plans in pg_stat_statements
|
| Список | pgsql-hackers |
> with the types of cached plan. We need to be able to differentiate
> when cached plans are not used, so a simple boolean is not
> sufficient.
Sure. But I modestly hope you would add a CachedPlanSource pointer
solely to the PlannedStmt and restructure it a little as we discussed
above. And no new structures are needed. Am I wrong?
That was my initial intention somehow to get CachedPlan available
to Executor hooks. But, as you pointed out there is more value in
CachedPlanSource.
I know Michael opposed the idea of carrying these structures,
at least CachedPlan, to Executor hooks ( or maybe just not QueryDesc?? ).
It will be good to see what he think, or if others an opinion about this, about
adding a pointer to CachedPlanSource in PlannedStmt vs setting a flag in
PlannedStmt to track plan cache type for the current execution? The former
does provide more capability for extensions, as Andrei has pointed out
earlier.
--
Sami
В списке pgsql-hackers по дате отправления: