Re: IDEA: pg_stat_statements tracking utility statements by tag?

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Martijn van Oosterhout <kleptog(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: IDEA: pg_stat_statements tracking utility statements by tag?
Date: 2020-07-30 04:57:31
Message-ID: CAOBaU_ZrfurXi1YxzJhK3z+4+AOWwv46=Eg66jxMc=6Obf=BOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 30, 2020 at 3:54 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Jul 29, 2020 at 06:35:41PM +0200, Julien Rouhaud wrote:
> > There's at least PREPARE TRANSACTION / COMMIT PREPARED / ROLLBACK
> > PREPARED that should be normalized too. I also don't think that we
> > really want to have different entries for begin / Begin / BEGIN /
> > bEgin and similar for many other commands, as the hash is computed
> > based on the query text.
>
> Hmm. Do we really want to those commands fully normalized all the
> time? There may be applications that care about the stats of some
> commands that are for example prefixed the same way and would prefer
> group those things together. By fully normalizing those commands all
> the time, we would lose this option.
>
> An example. The ODBC driver uses its own grammar for internal
> savepoint names, aka _EXEC_SVP_%p. If you mix that with a second
> application that has its own naming policy for savepoints it would not
> be possible anymore to make the difference in the stats between what
> one or the other do.

But if you have an OLTP application that uses ODBC, won't you already
have 80+% of pgss entries being savepoint orders, which is really not
helpful at all? We'd technically lose the ability to group such
commands together, but in most cases the current behavior is quite
harmful.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-07-30 05:16:04 Re: [PATCH] Tab completion for VACUUM of partitioned tables
Previous Message Peter Geoghegan 2020-07-30 04:18:44 Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.