Re: track generic and custom plans in pg_stat_statements

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