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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: 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: Thu, 24 Jul 2025 11:05:10 -0400
Message-ID: <1647760.1753369510@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMMNXX=9Z-OiLLMOk0o8DJX9tNs5MA_qYWJ4VNFZbMPywBYQ8w@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>

Andrei Lepikhov <lepihov@gmail.com> writes:
> I see you have chosen a variant with a new enum instead of a pointer to
> a plan cache entry. I wonder if you could write the arguments
> supporting this choice?

Pointing to a plan cache entry would often mean that the data
structure as a whole is circular (since a plan cache entry
will have a pointer to a plan).  That would in particular
make it unsafe for the plan to protect its pointer by incrementing
the cache entry's refcount --- the assemblage could never go away.
So I concur with Michael that what you propose is a bad idea.

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
replanning events.

			regards, tom lane





view thread (73+ messages)  latest in thread

Message-ID: <1647760.1753369510@sss.pgh.pa.us>
Permalink:  ../1647760.1753369510@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1647760.1753369510@sss.pgh.pa.us

 · 

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: tgl@sss.pgh.pa.us, lepihov@gmail.com, michael@paquier.xyz, 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: <1647760.1753369510@sss.pgh.pa.us>

* 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