Re: Issue in recent pg_stat_statements?

From: David Christensen <david(dot)christensen(at)crunchydata(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issue in recent pg_stat_statements?
Date: 2021-04-26 17:53:30
Message-ID: CAOxo6XK5f0VPM-RhgpZq2s6wiOV6isnEC2tsgNyPfZd8pD0PYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 26, 2021 at 12:18 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:

> On Mon, Apr 26, 2021 at 11:40 PM David Christensen
> <david(dot)christensen(at)crunchydata(dot)com> wrote:
> >>
> >> > Is this an expected change, or is this in fact broken? In previous
> revisions, this was showing the INSERT and SELECT at the very least. I'm
> unclear as to why the regression test is still passing, so want to verify
> that I'm not doing something wrong in the testing.
> >>
> >> Yes, you want to look into the queryid functionality. See
> >>
> https://www.postgresql.org/message-id/flat/35457b09-36f8-add3-1d07-6034fa585ca8%40oss.nttdata.com
> >>
> >> Interface changes may still be coming in 14 for that. Or warnings.
> >
> >
> > Hmm, I'm unclear as to why you would potentially want to use
> pg_stat_statements *without* this functionality.
>
> Using pg_stat_statements with a different query_id semantics without
> having to fork pg_stat_statements.
>

I can see that argument for allowing alternatives, but the current default
of nothing seems to be particularly non-useful, so some sensible default
value would seem to be in order, or I can predict a whole mess of future
user complaints.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-04-26 18:08:31 Re: Issue in recent pg_stat_statements?
Previous Message Mark Dilger 2021-04-26 17:52:34 Re: pg_amcheck contrib application