Re: track generic and custom plans in pg_stat_statements - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: track generic and custom plans in pg_stat_statements
Date
Msg-id aInHvKN4Gsztmopy@paquier.xyz
Whole thread Raw
In response to Re: track generic and custom plans in pg_stat_statements  (Sami Imseih <samimseih@gmail.com>)
Responses Re: track generic and custom plans in pg_stat_statements
List pgsql-hackers
On Tue, Jul 29, 2025 at 05:08:09PM -0500, Sami Imseih wrote:
> 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.

Okay by me for having a default that maps to something else than the
rest.

+   PLAN_STMT_NOT_SET = 0,      /* origin not yet set */

The term "NOT_SET" makes me itch a little bit, even if there is an
existing parallel with OverridingKind.  Perhaps your proposal is OK,
still how about "UNKNOWN" instead to use as term for the default?

> In pgss_store, I don't want to pass the entire PlannedStmt,

Neither do I.

> 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.

Okay.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Support getrandom() for pg_strong_random() source
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: POC: enable logical decoding when wal_level = 'replica' without a server restart