| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrei Lepikhov <lepihov(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-29 22:08:09 |
| Message-ID: | CAA5RZ0sYd6-KeQqR4uLFS1swBh37jKJCzR_E-G373EuLKm5UzA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Attached is my counter-proposal, where I have settled down to four
> > categories of PlannedStmt:
> > - "standard" PlannedStmt, when going through the planner.
> > - internally-generated "fake" PlannedStmt.
> > - custom cache
> > - generic cache
>
> Thanks for the update! I plan on reviewing this tomorrow.
The only comment I have is I think we need a NOT_SET
member, so it can simplify the life of extensions that have code
paths which may or may not have a PlannedStmt, such as
pgss_store. In pgss_store, I don't want to pass the entire PlannedStmt,
nor do I want to pass PLAN_STMT_INTERNAL in the call during
post_parse_analyze, in which case we don't have a plan. Using
PLAN_STMT_INTERNAL as a default value if odd.
v15 includes the change with the above as well as the pg_stat_statements
changes.
--
Sami
| Attachment | Content-Type | Size |
|---|---|---|
| v15-0001-Introduce-planOrigin-field-in-PlannedStmt-to-rep.patch | application/octet-stream | 7.8 KB |
| v15-0002-Add-counters-for-generic-and-custom-plans.patch | application/octet-stream | 5.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2025-07-29 22:11:01 | Re: C11 / VS 2019 |
| Previous Message | Jelte Fennema-Nio | 2025-07-29 21:20:24 | Re: BackendKeyData is mandatory? |