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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yun Li <liyunjuanyong@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-16T14:32:16Z
Lists: pgsql-hackers
On Fri, Mar 15, 2019 at 9:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yun Li <liyunjuanyong@gmail.com> writes:
> > Do you think if we can add queryId into the pg_stat_get_activity function
> > and ultimatly expose it in the view? It would be easier to track "similar"
> > query's performance over time easier.
>
> No, we're not likely to do that, because it would mean (1) baking one
> single definition of "query ID" into the core system and (2) paying
> the cost to calculate that ID all the time.
>
> 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.  There's only one query ID field available, and
you can't use two extensions that care about query ID unless they
compute it the same way, and replicating all the code that computes
the query ID into each new extension that wants one sucks.  I think we
should actually bite the bullet and move all of that code into core,
and then just let extensions say whether they care about it getting
set.

Also, I think this is now the third independent request to expose
query ID in pg_stat_statements.  I think we should give the people
what they want.

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


Commits

  1. Clarify description of pg_stat_statements columns

  2. Fix wording in description of pg_stat_statements.toplevel

  3. Mention that toplevel is part of pg_stat_statements key.

  4. adjust query id feature to use pg_stat_activity.query_id

  5. Update copyright for 2021

  6. Take the statistics collector out of the loop for monitoring backends'