Message-ID: <5f775987-8a93-452d-bb3f-a1de53836406@gmail.com>
Date: Wed, 16 Jul 2025 14:41:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: track generic and custom plans in pg_stat_statements
To: Sami Imseih <samimseih@gmail.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Nikolay Samokhvalov <nik@postgres.ai>,
 Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
References: 
 <CAA5RZ0uFw8Y9GCFvafhC=OA8NnMqVZyzXPfv_EePOt+iv1T-qQ@mail.gmail.com>
 <6f5b6a25-7391-4233-9238-7ba4f5563ef8@tantorlabs.com>
 <CAA5RZ0uT1DqOw5X0r0fB68qpYRqNdREv9A8izqQu6k1LMwkByg@mail.gmail.com>
 <b33a4d04-6cbd-49d4-ba9f-b2b001a154d5@tantorlabs.com>
 <CAA5RZ0vqVPD0-h+MukmNBkfP11oV_2=T+pKidyeUQbBWRTMbmA@mail.gmail.com>
 <CAA5RZ0sxV3APLzmnH1Jt0ehmjzYAStNqcZeEAma_D0VkmjkX8w@mail.gmail.com>
 <1d667f28-c739-417b-b024-7f5c1004a008@tantorlabs.com>
 <CAA5RZ0sUcVngZHLG_Q_N=OD9QhC+SJf0dx7HsPX9U4SJQF20gA@mail.gmail.com>
 <CAA5RZ0t5w8mx5hb9KEFv29FFK+AScOSUuXE4raQ_pHQTFQUotw@mail.gmail.com>
 <CAM527d9jo-EPHwVwGym3fxmiebtKhhM9q8F5WGsK7S4XCsMGrA@mail.gmail.com>
 <CAA5RZ0vGBFHvGb4iZdmSADuybkHGNrxVHknTGaEhS2=2LcM56g@mail.gmail.com>
 <CAA5RZ0tpO_LwFNW3UJGLfK2_BNS+bgKKrKS10M1saOoGW42sKw@mail.gmail.com>
 <60f09467-bfe6-49bc-a47a-fe887050a23a@tantorlabs.com>
 <CAA5RZ0v4Lqc3KOzFCOJd0hjBpF10W=-E6xn0z_HizZY9uxPR0w@mail.gmail.com>
 <CAA5RZ0vK_fah+ZS00hdg9uH2J_zBgV75x6ojYrc6+OJudnbKtQ@mail.gmail.com>
Content-Language: en-AU
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CAA5RZ0vK_fah+ZS00hdg9uH2J_zBgV75x6ojYrc6+OJudnbKtQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/5f775987-8a93-452d-bb3f-a1de53836406%40gmail.com>
Precedence: bulk

On 6/30/25 13:45, Sami Imseih wrote:
> rebased patch.
> 
> Only changes to the tests due to the revert of nested query
> tracking in f85f6ab051b
Thank you for your efforts.

I would like to share a few thoughts about this patch. First, I believe 
the 'status' field could be renamed to 'mode,' as it aligns better with 
the plan_cache_mode GUC name. Additionally, why introduce an unknown 
status? I can't foresee a scenario where it would be necessary, as we 
typically encounter either a custom or a generic plan during execution.

On a more general note, currently, CachedPlanSource does not refer to a 
custom version of the plan. However, it seems reasonable to implement 
this for better tracking. By adding a CachedPlanSource::cplan link, we 
can establish a connection to the entire PlanCache entry instead of only 
CachedPlan within a queryDesc and, consequently, make it accessible from 
the executor. This would give an access to statistics on costs and the 
number of replannings.

Furthermore, this could lead to interesting opportunities for 
extensions, such as resetting auto-mode decisions and planning 
statistics based on actual execution statistics, and manipulating 
generic/custom plan switching logic.

-- 
regards, Andrei Lepikhov