Re: track generic and custom plans in pg_stat_statements

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-25 15:29:01
Message-ID: CAA5RZ0t54uP+O2dGZCoYfzOU_wcT2trVL65GdZB00RiLDs9BCg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Perhaps CachedPlanType is
> misnamed, though, would it be more suited to name that as a sort of
> "origin" or "source" field concept? We want to know which which
> source we have retrieved a plan that a PlannedStmt refers to.

Hmm, I’m not sure I see this as an improvement. In my opinion,
CachedPlanType is a clear name that describes its purpose.

--
Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-07-25 15:30:02 Re: Logical replication launcher did not automatically restart when got SIGKILL
Previous Message Hironobu SUZUKI 2025-07-25 15:26:21 [PATCH] Avoid unnecessary code execution in Instrument.c when TIMING is FALSE