From: Andrei Lepikhov <lepihov@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Sabino Mullane <htamfids@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Nikolay Samokhvalov <nik@postgres.ai>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Subject: Re: track generic and custom plans in pg_stat_statements
Date: Wed, 30 Jul 2025 10:20:52 +0200
Message-ID: <87249b23-c4c5-4c0b-88d3-efb13b8a04d1@gmail.com> (raw)
In-Reply-To: <aInHvKN4Gsztmopy@paquier.xyz>
References: <CAA5RZ0sxC0=2wZ-QaRB7FdMmQ4_BYKG=X+gdDGHnS6KTrfgLQA@mail.gmail.com>
<1673684.1753379027@sss.pgh.pa.us>
<CAA5RZ0sQuoHJsGc-dJV15yYURuXsOp2pwr9hLAk+pcm7=MAK2w@mail.gmail.com>
<aILaHupXbIGgF2wJ@paquier.xyz>
<CAA5RZ0t54uP+O2dGZCoYfzOU_wcT2trVL65GdZB00RiLDs9BCg@mail.gmail.com>
<1933906.1753462272@sss.pgh.pa.us>
<CAA5RZ0t4A4PVLHK5DPZWCsZvtviLf==PGG5eiy6Bm0DCpchHyQ@mail.gmail.com>
<aIcWKh8wK2GWFMFz@paquier.xyz>
<CAA5RZ0t6GctNqFA60_ajhw0D+9DeuHYa7F2QCQMumTxx=h3UZQ@mail.gmail.com>
<CAA5RZ0sYd6-KeQqR4uLFS1swBh37jKJCzR_E-G373EuLKm5UzA@mail.gmail.com>
<aInHvKN4Gsztmopy@paquier.xyz>
On 30/7/2025 09:20, Michael Paquier wrote:
> 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?
+1 to "UNKNOWN".
There may be various sources for query plans. For instance, in the plan
freezing extension, I often bypass the standard planner completely by
using a plan created in another backend and serialised in shared memory.
Additionally, there is a concept of comparing hinted plans with those
generated freely after an upgrade, which would serve as an extra source
of plans.
One extra example - I sometimes build a 'referenced generic plan', using
incoming constants as a source for clause selectivity calculations,
building a generic plan, likewise SQL Server or Oracle implemented
generics. It seems like a 'hybrid' type of plan ;).
But generally, classification in the PlannedStmtOrigin structure seems a
little strange: a generic plan has a qualitative difference from any
custom one. And any other plan also will be generic or custom, doesn't
it? It is interesting information about the plan source, of course, but
for the sake of performance analysis, it would be profitable to
understand the type of plan. However, the last sentence may be a subject
for another thread.
--
regards, Andrei Lepikhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: lepihov@gmail.com, michael@paquier.xyz, samimseih@gmail.com, tgl@sss.pgh.pa.us, htamfids@gmail.com, nik@postgres.ai, ilya.evdokimov@tantorlabs.com
Subject: Re: track generic and custom plans in pg_stat_statements
In-Reply-To: <87249b23-c4c5-4c0b-88d3-efb13b8a04d1@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox