On Wed, Jul 29, 2020 at 2:42 PM Fujii Masao <masao.fu...@oss.nttdata.com> wrote: > > On 2020/07/29 18:24, Martijn van Oosterhout wrote: > > Hoi hackers, > > > > We've been using the pg_stat_statements extension to get an idea of the > > queries used in the database, but the table is being filled with entries > > like: > > > > SAVEPOINT sa_savepoint_NNN; > > RELEASE SAVEPOINT sa_savepoint_NNN; > > DECLARE "c_7f9451c4dcc0_5" CURSOR WITHOUT HOLD ... > > FETCH FORWARD 250 FROM "c_7f9451b03908_5" > > > > Since the unique id is different for each query, the aggregation does > > nothing and there are quite a lot of these drowning out the normal queries > > (yes, I'm aware this is an issue of itself). The only way to deal with this > > is "pg_stat_statements.track_utility=off". However, it occurs to me that if > > you just tracked the tags rather than the full query text you could at > > least track the number of such queries and how much time they take. So the > > above queries would be tracked under SAVEPOINT, RELEASE, DECLARE CURSOR and > > (I guess) FETCH respectively. But it would also catch DDL. > > > > Does this sound like something for which a patch would be accepted? > > Or, we should extend the existing query normalization to handle also DDL?
+1, introducing DDL normalization seems like a better way to go in the long run. Defining what should and shouldn't be normalized can be tricky though.
