Message-ID: <03f82e6f-66a3-4c4d-935c-ea4d93871dc1@gmail.com>
Date: Tue, 22 Jul 2025 14:04:31 +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>, Michael Paquier <michael@paquier.xyz>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>,
 Greg Sabino Mullane <htamfids@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Nikolay Samokhvalov <nik@postgres.ai>
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>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CAA5RZ0sy2_Dn5kwPy4JnELZeva2CgO01=jPrR7zwUWY0p7VgrQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/03f82e6f-66a3-4c4d-935c-ea4d93871dc1%40gmail.com>
Precedence: bulk

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