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: Michael Paquier <michael@paquier.xyz>
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: Tue, 22 Jul 2025 22:12:04 +0200
Message-ID: <09a82e0c-8c37-4366-9807-6553fa83a3b0@gmail.com> (raw)
In-Reply-To: <CAA5RZ0sX=ZUZ0tFa3c3bQ4BWN4g7RbGUhg60GkP=5P-+XLJywA@mail.gmail.com>
References: <CAA5RZ0v4Lqc3KOzFCOJd0hjBpF10W=-E6xn0z_HizZY9uxPR0w@mail.gmail.com>
	<CAA5RZ0vK_fah+ZS00hdg9uH2J_zBgV75x6ojYrc6+OJudnbKtQ@mail.gmail.com>
	<5f775987-8a93-452d-bb3f-a1de53836406@gmail.com>
	<CAA5RZ0uxcVu9MPXQc6qJ5mtYhH=_7b7jjaDnvg6Sft8jJ1NbXw@mail.gmail.com>
	<56d31e81-79d8-40bd-b957-0d6dc7c46589@gmail.com>
	<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>

On 7/22/25 19:13, Sami Imseih wrote:
>> It may be more efficient to set the is_generic_plan option at the top
>> plan node (PlannedStmt) and reference it wherever necessary. To identify
>> a cached plan, we may consider pushing the CachedPlan/CachedPlanSource
>> pointer down throughout pg_plan_query and maintaining a reference to the
>> plan (or simply setting a boolean flag) at the same location — inside
>> the PlannedStmt.
> 
> We will need a field to store an enum. let's call it CachedPlanType
> with the types of cached plan. We need to be able to differentiate
> when cached plans are not used, so a simple boolean is not
> sufficient.
Sure. But I modestly hope you would add a CachedPlanSource pointer 
solely to the PlannedStmt and restructure it a little as we discussed 
above. And no new structures are needed. Am I wrong?

-- 
regards, Andrei Lepikhov





view thread (73+ messages)  latest in thread

Message-ID: <09a82e0c-8c37-4366-9807-6553fa83a3b0@gmail.com>
Permalink:  ../09a82e0c-8c37-4366-9807-6553fa83a3b0@gmail.com/
Also on:    postgresql.org/message-id/09a82e0c-8c37-4366-9807-6553fa83a3b0@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, michael@paquier.xyz, htamfids@gmail.com, nik@postgres.ai, ilya.evdokimov@tantorlabs.com
  Subject: Re: track generic and custom plans in pg_stat_statements
  In-Reply-To: <09a82e0c-8c37-4366-9807-6553fa83a3b0@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