Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 25 Jul 2025 10:13:02 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrei Lepikhov <lepihov@gmail.com>,
	Greg Sabino Mullane <htamfids@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	Nikolay Samokhvalov <nik@postgres.ai>,
	Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Subject: Re: track generic and custom plans in pg_stat_statements
Message-ID: <aILaHupXbIGgF2wJ@paquier.xyz>
References: <a0432b5d-84e1-4678-9963-bf5ecb749dd0@gmail.com>
 <CAA5RZ0sX=ZUZ0tFa3c3bQ4BWN4g7RbGUhg60GkP=5P-+XLJywA@mail.gmail.com>
 <CAA5RZ0tA43qf1HF1g6oYUGNBGFr23F29pf4F9Hymp2z8PyTsPg@mail.gmail.com>
 <aIBTulWwle8XseNt@paquier.xyz>
 <aIHarYaprfxOl7bU@paquier.xyz>
 <CAMMNXX=9Z-OiLLMOk0o8DJX9tNs5MA_qYWJ4VNFZbMPywBYQ8w@mail.gmail.com>
 <1647760.1753369510@sss.pgh.pa.us>
 <CAA5RZ0sxC0=2wZ-QaRB7FdMmQ4_BYKG=X+gdDGHnS6KTrfgLQA@mail.gmail.com>
 <1673684.1753379027@sss.pgh.pa.us>
 <CAA5RZ0sQuoHJsGc-dJV15yYURuXsOp2pwr9hLAk+pcm7=MAK2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="IwB45JZ+LRckAgQf"
Content-Disposition: inline
In-Reply-To: 
 <CAA5RZ0sQuoHJsGc-dJV15yYURuXsOp2pwr9hLAk+pcm7=MAK2w@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aILaHupXbIGgF2wJ%40paquier.xyz>
Precedence: bulk


--IwB45JZ+LRckAgQf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Jul 24, 2025 at 01:14:47PM -0500, Sami Imseih wrote:
>> Sami Imseih <samimseih@gmail.com> writes:
>>>> 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
>>
>>> One possible hook for accumulating custom and generic plans per
>>> queryId would be inside GetCachedPlan. However, this would require
>>> calling pgss_store an extra time, in addition to ExecutorEnd, every time
>>> GetCachedPlan is executed, which could introduce non-negligible
>>> overhead.

I would suspect more contention on the PGSS locks in the prepared
statement and/or extended query protocol case if we were to do that.
With the amount of information we want to track in PGSS, which is that
we want to know from where a plan is coming from (generic cache,
custom cache or something else), FWIW I'm still OK with this
information added in PlannedStmt itself to be able to link back to the
state retrieved at the end of the executor because it's also
cost-free.

I'm also OK to be proved wrong based on arguments that could justify
the addition of an extra hook, but I don't really see the use-cases
that could justify such additions yet.  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.
--
Michael

--IwB45JZ+LRckAgQf
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmiC2h4ACgkQnvQgOdby
QH2BUg//U1N07SEj4r4MPCzzDrzYE+xG5Ybi/QepledS51/BKqd67fRMFgcQ8UqA
XmaKS9BJQBIZbk9mMZErnCyZFKmKkw3TslKnGBH2riC4l1gKzNZDUoeKRsNKfcnH
6Ev7GXX9Hemwc34LrXcgXti0t6S3AypqoOvKCG1oVQT0Loq8o70rtq5cZgjdClUP
Ohg+bU4BtbicX79h8jWdyEMQUc4idmc10z+/+vCtx6Xhw6BGAuw3IbRqc28Bv80s
ybxiYeWJSM7mvgfsgumLRsEY5X4SEcsdEguJIyEmF706Z3pB9ukrJdYvL9dS0clN
KhD6OPLAhS/YRBJkAqVDWwGKWFNm7TJeaZ+ItTjOMtGDQZfCd9ojtXfHTsluKrH9
MtC01NgEUfn7I+jd8qddIXB7ENoIx1PaNmBwUef2GMD9uyksn8bZ23OB4vqfZKXm
SJaL5mjFJQBSpD3righ1M+gyeHDUwq8SLQozvt3MtvLzjlmPt1vND7DopeswX+YV
f5PxwUeyNV9lF2iD5NZACAFUlqVdGQewxkqfsZBnYfxxgM7Yf2348xIDEk4CixSV
45QGxQQjiJAU3OOvRtSKkTZWvcckyFjXYlnHlT39GvM2xJr5sgz/OC+PgJUERKov
xv1u28U+vhdRivFBM9eMUOGJLGkSP9EmVKSaQlMG3p9W07eO9s4=
=A/oB
-----END PGP SIGNATURE-----

--IwB45JZ+LRckAgQf--