From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sami Imseih <samimseih@gmail.com>
cc: Andrei Lepikhov <lepihov@gmail.com>,
 Michael Paquier <michael@paquier.xyz>,
        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
In-reply-to: 
 <CAA5RZ0sxC0=2wZ-QaRB7FdMmQ4_BYKG=X+gdDGHnS6KTrfgLQA@mail.gmail.com>
References: 
 <CAA5RZ0tdc4HeHdFRvVPWBdXP1JwCSjPPgiQyFk8fwhv=4fKmjw@mail.gmail.com>
 <2f2bde53-972d-402c-9da3-c5467cca00bf@gmail.com>
 <CAA5RZ0tfr50T1xYET=1Ei=NkbmS3e7MFhMJTrnoLi2oO7n2JsQ@mail.gmail.com>
 <064b9efd-92c9-4670-95f4-d911d4c7ddeb@gmail.com>
 <CAA5RZ0ss-jmqeze0G8anztzLRJuMEgz9y3gTd-rgTc2Ejtwzvg@mail.gmail.com>
 <aH7IPp_Hku02xHP2@paquier.xyz>
 <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>
Comments: In-reply-to Sami Imseih <samimseih@gmail.com>
	message dated "Thu, 24 Jul 2025 11:52:28 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1673683.1753379027.1@sss.pgh.pa.us>
Date: Thu, 24 Jul 2025 13:43:47 -0400
Message-ID: <1673684.1753379027@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1673684.1753379027%40sss.pgh.pa.us>
Precedence: bulk

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.

Only if you insist that the way to handle this is to call pgss_store
at that time.  I'd be inclined to think about having some transient
process-local data structure that can remember the info until
ExecutorEnd.  But the plan tree is not the right place, because of
the circularity problem.

			regards, tom lane