| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
| Subject: | Re: track generic and custom plans in pg_stat_statements |
| Date: | 2025-07-22 20:28:24 |
| Message-ID: | CAA5RZ0s=K+CvM6dZcYnvzitsU0g7btDjRpVjOU8PAh8PP=zX5w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2025-07-22 20:28:37 | Re: index prefetching |
| Previous Message | Andrei Lepikhov | 2025-07-22 20:12:04 | Re: track generic and custom plans in pg_stat_statements |