| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, 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-24 18:22:22 |
| Message-ID: | CAA5RZ0t6fHWd7haB-3F=NZvD22NKKAkdvDM4Y2-3uQJQ0EV9GQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> One option might be to use a local hash table, keyed the same way as the
> shared pgss hash (excluding dbid), to handle cases where a backend has
> more than one active cached plan. Then at ExecutorEnd, the local entry could
> be looked up and passed to pgss_store. Not sure if this is worth the effort vs
> what has been committed.
I should also add that making this information available in PlannedStmt allows
for EXPLAIN to also utilize this information. I am thinking we can add
this information
as part of core EXPLAIN or as an option in pg_overexplain.
--
Sami
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vik Fearing | 2025-07-24 18:24:29 | Re: [PATCH] Generate random dates/times in a specified range |
| Previous Message | Sami Imseih | 2025-07-24 18:14:47 | Re: track generic and custom plans in pg_stat_statements |