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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Atsushi Torikoshi <atorik(at)gmail(dot)com>, Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Evgeny Efimkin <efimkin(at)yandex-team(dot)ru>, 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: 2020-10-16 16:03:55
Message-ID: 20201016160355.GA31474@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Oct-16, Bruce Momjian wrote:

> On Thu, Oct 15, 2020 at 11:41:23AM +0800, Julien Rouhaud wrote:

> > I did some naive benchmarking. Using a custom pgbench script with this query:

> > I can see around 2% overhead (this query is reported with ~ 3ms
> > latency average). Adding a few joins, overhead goes down to 1%.
>
> That number is too high to enable this by default. I suggest we either
> improve the performance of this, or clearly document that you have to
> enable the hash computation to see the pg_stat_activity and
> log_line_prefix fields.

Agreed. This is similar to how we used to deal with query strings: an
optional feature, disabled by default (cf. commit b13c9686d084).

In this case, I suppose using pg_stat_statement would require to have it
enabled, and it'd just not collect anything if disabled. Similarly, the
field would show NULL in pg_stat_activity or an empty string in
log_line_prefix/CSV logs.

So users that want it can easily have it, and users that don't are not
paying the price.

For maximum user-friendliness, pg_stat_statement could be loaded and
shmem-initialized even when query ID computation is turned off, and
you'd be able to enable query ID computation with just SIGHUP; so you
don't have to restart the server in order to enable statement tracking.
(I suppose we would forbid users from disabling query ID with SET,
though.)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-10-16 16:18:32 Re: Sometimes the output to the stdout in Windows disappears
Previous Message Stephen Frost 2020-10-16 16:00:29 Re: [Patch] Using Windows groups for SSPI authentication