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>
To: Michael Paquier <michael@paquier.xyz>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Nikolay Samokhvalov <nik@postgres.ai>
Subject: Re: track generic and custom plans in pg_stat_statements
Date: Tue, 22 Jul 2025 14:04:31 +0200
Message-ID: <03f82e6f-66a3-4c4d-935c-ea4d93871dc1@gmail.com> (raw)
In-Reply-To: <CAA5RZ0sy2_Dn5kwPy4JnELZeva2CgO01=jPrR7zwUWY0p7VgrQ@mail.gmail.com>
References: <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>
	<aHdAQskQCjGWOdfi@paquier.xyz>
	<CAA5RZ0sy2_Dn5kwPy4JnELZeva2CgO01=jPrR7zwUWY0p7VgrQ@mail.gmail.com>

On 22/7/2025 01:22, Sami Imseih wrote:
>> Note: the size of the change in pg_stat_statements--1.12--1.13.sql
>> points that we should seriously consider splitting these attributes
>> into multiple sub-functions.
> 
> So we don't lose track of this. This should be a follow-up thread. I do
> agree something has to be done about the exploding list of attributes
> in pg_s_s.
+1

Not once I encountered people who want to track only a specific number 
of parameters and do not have much fun burdening themselves with all the 
data set, querying a whole huge stat view to analyse performance profiles.
In another scenario, an extension needs to track a limited number of 
parameters - let's say, blocks hit and blocks read. Another dimension - 
sometimes we are only interested in queries that involve complex join 
trees or partitioned tables and would be happy to avoid tracking all 
other queries.
It seems that a callback-based or subscription-based model could be 
worth exploring.

-- 
regards, Andrei Lepikhov





view thread (73+ messages)  latest in thread

Message-ID: <03f82e6f-66a3-4c4d-935c-ea4d93871dc1@gmail.com>
Permalink:  ../03f82e6f-66a3-4c4d-935c-ea4d93871dc1@gmail.com/
Also on:    postgresql.org/message-id/03f82e6f-66a3-4c4d-935c-ea4d93871dc1@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, ilya.evdokimov@tantorlabs.com, htamfids@gmail.com, nik@postgres.ai
  Subject: Re: track generic and custom plans in pg_stat_statements
  In-Reply-To: <03f82e6f-66a3-4c4d-935c-ea4d93871dc1@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