Re: IDEA: pg_stat_statements tracking utility statements by tag?

From: Martijn van Oosterhout <kleptog(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: 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-29 15:29:42
Message-ID: CADWG95tz1gHFio3MS7RGcb1ftOuB3JdiFGWuORVnGdXce-j=Wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 29 Jul 2020 at 15:40, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:

> On Wed, Jul 29, 2020 at 2:42 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
> wrote:
> >
> >
> > 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.
>

In principle, the only thing that really needs to be normalised is
SAVEPOINT/CURSOR names which are essentially random strings which have no
effect on the result. Most other stuff is material to the query.

That said, I think "aggregate by tag" has value all by itself. Being able
to collapse all CREATE TABLES into a single line can be useful in some
situations.

Ideally the results of FETCH "cursor" should be combined with the DECLARE,
but I really don't know how to go about that.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)gmail(dot)com> http://svana.org/kleptog/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-07-29 15:31:26 Re: refactoring basebackup.c
Previous Message Fujii Masao 2020-07-29 15:24:26 Re: Nicer error when connecting to standby with hot_standby=off