Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date
Msg-id CA+TgmoaK55MiAU1wxizK05ZkxK8KKj83P2WxWCTQ7LLe9P6RCA@mail.gmail.com
Whole thread Raw
In response to Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
List pgsql-hackers
On Mon, Oct 12, 2020 at 10:14 AM Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, Oct 12, 2020 at 04:20:05PM +0800, Julien Rouhaud wrote:
> > But there are many people that aren't happy with the current hashing
> > approach.  If we're going to move the computation in core, shouldn't
> > we listen to their complaints and let them pay some probably quite
> > high overhead to base the hash on name and/or fully qualified name
> > rather than OID?
> > For instance people using logical replication to upgrade to a newer
> > version may want to easily compare query performance on the new
> > version, or people with multi-tenant databases may want to ignore the
> > schema name to keep a low number of different queryid.
>
> Well, we have to consider how complex the user interface has to be to
> allow more flexibility.  We don't need to allow every option a user will
> want.
>
> With a version number, we have the ability to improve the algorithm or
> add customization, but for the first use, we are probably better off
> keeping it simple.

I thought your earlier idea of allowing this to be controlled by a GUC
was good. There could be a default method built into core, matching
what pg_stat_statements does, so you could select no hashing or that
method no matter what. Then extensions could provide other methods
which could be selected via the GUC.

I don't really understand how a version number helps. It's not like
there is going to be a v2 that is in all ways better than v1. If there
are different algorithms here, they are going to be customized for
different needs.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: partition routing layering in nodeModifyTable.c
Next
From: Robert Haas
Date:
Subject: Re: libpq debug log