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
