pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andrei Lepikhov <lepihov@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
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, 16 Jul 2025 14:41:20 +0200
Message-ID: <5f775987-8a93-452d-bb3f-a1de53836406@gmail.com> (raw)
In-Reply-To: <CAA5RZ0vK_fah+ZS00hdg9uH2J_zBgV75x6ojYrc6+OJudnbKtQ@mail.gmail.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>

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





view thread (73+ messages)  latest in thread

Message-ID: <5f775987-8a93-452d-bb3f-a1de53836406@gmail.com>
Permalink:  ../5f775987-8a93-452d-bb3f-a1de53836406@gmail.com/
Also on:    postgresql.org/message-id/5f775987-8a93-452d-bb3f-a1de53836406@gmail.com

 · 

reply
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, samimseih@gmail.com, htamfids@gmail.com, nik@postgres.ai, ilya.evdokimov@tantorlabs.com
  Subject: Re: track generic and custom plans in pg_stat_statements
  In-Reply-To: <5f775987-8a93-452d-bb3f-a1de53836406@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