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.
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 |