Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Yun Li <liyunjuanyong(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date: 2019-03-16 18:02:52
Message-ID: CAOBaU_aQzRosCQtnSQFRKCpQSh7857xWWRpBtBMtmZa+3Ybcuw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 16, 2019 at 5:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Fri, Mar 15, 2019 at 9:50 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> pg_stat_statements has a notion of query ID, but that notion might be
> >> quite inappropriate for other usages, which is why it's an extension
> >> and not core.
>
> > Having written an extension that also wanted a query ID, I disagree
> > with this position.
>
> [ shrug... ] The fact remains that pg_stat_statements's definition is
> pretty lame. There's a lot of judgment calls in which query fields
> it chooses to examine or ignore, and there's been no attempt at all
> to make the ID PG-version-independent, and I rather doubt that it's
> platform-independent either. Nor will the IDs survive a dump/reload
> even on the same server, since object OIDs will likely change.
>
> These things are OK, or at least mostly tolerable, for pg_stat_statements'
> usage ... but I don't think it's a good idea to have the core code
> dictating that definition to all extensions. Right now, if you have
> an extension that needs some other query-ID definition, you can do it,
> you just can't run that extension alongside pg_stat_statements.
> But you'll be out of luck if the core code starts filling that field.
>
> I'd be happier about having the core code compute a query ID if we
> had a definition that was not so obviously slapped together.

But the queryId itself is stored in core. Exposing it in
pg_stat_activity or log_line_prefix would still allow users to choose
the implementation of their choice, or none. That seems like a
different complaint from asking pgss integration in core to have all
its metrics available by default (or at least without a restart).

Maybe we could add a GUC for pg_stat_statements to choose whether it
should set the queryid itself and not, if anyone wants to have its
metrics but with different queryid semantics?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-03-16 18:11:58 Re: jsonpath
Previous Message Tom Lane 2019-03-16 17:59:04 Re: jsonpath