| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Sami Imseih <samimseih(at)gmail(dot)com>, 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 15:05:10 |
| Message-ID: | 1647760.1753369510@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
> I see you have chosen a variant with a new enum instead of a pointer to
> a plan cache entry. I wonder if you could write the arguments
> supporting this choice?
Pointing to a plan cache entry would often mean that the data
structure as a whole is circular (since a plan cache entry
will have a pointer to a plan). That would in particular
make it unsafe for the plan to protect its pointer by incrementing
the cache entry's refcount --- the assemblage could never go away.
So I concur with Michael that what you propose is a bad idea.
That is not to say that I think 719dcf3c4 was a good idea: it looks
rather useless from here. It seems to me that the right place to
accumulate these sorts of stats is in CachedPlanSources, and I don't
see how this helps. What likely *would* help is some hooks in
plancache.c for pg_stat_statements to connect into so it can count
replanning events.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Damien Clochard | 2025-07-24 15:20:12 | Re: [PATCH] Generate random dates/times in a specified range |
| Previous Message | Laurenz Albe | 2025-07-24 14:57:42 | Commitfest 2025-03 still has active patches |