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

From Bruce Momjian
Subject Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date
Msg-id 20210408153425.GC2439@momjian.us
Whole thread Raw
In response to Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Wed, Apr  7, 2021 at 11:27:04PM -0400, Álvaro Herrera wrote:
> On 2021-Apr-07, Bruce Momjian wrote:
> 
> > On Thu, Apr  8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote:
> 
> > > Thanks!  And I agree with using query_id in the new field names while keeping
> > > queryid for pg_stat_statements to avoid unnecessary query breakage.
> > 
> > I think we need more feedback from the group.  Do people agree with the
> > idea above?  The question is what to call:
> > 
> >     GUC compute_queryid
> >     pg_stat_activity.queryid
> >     pg_stat_statements.queryid
> > 
> > using "queryid" or "query_id", and do they have to match?
> 
> Seems a matter of personal preference.  Mine is to have the underscore
> everywhere in backend code (where this is new), and let it without the
> underscore in pg_stat_statements to avoid breaking existing code.  Seems
> to match what Julien is saying.

OK, let's get some details.  First, pg_stat_statements.queryid already
exists (no underscore), and I don't think anyone wants to change that. 

pg_stat_activity.queryid is new, but I can imagine cases where you would
join pg_stat_activity to pg_stat_statements to get an estimate of how
long the query will take --- having one using an underscore and another
one not seems odd.  Also, looking at the existing pg_stat_activity
columns, those don't use underscores before the "id" unless there is a
modifier before the "id", e.g. "pid", "xid":

    SELECT    attname
    FROM    pg_namespace JOIN pg_class ON (pg_namespace.oid = relnamespace)
             JOIN pg_attribute ON (pg_class.oid = pg_attribute.attrelid)
    WHERE    nspname = 'pg_catalog' AND
        relname = 'pg_stat_activity' AND
        attname ~ 'id$';
       attname
    -------------
     backend_xid
     datid
     leader_pid
     pid
     queryid
     usesysid

We don't have a modifier before queryid.

If people like query_id, and I do too, I am thinking we just keep
query_id as the GUC (compute_query_id), and just accept that the GUC and
SQL levels will not match.  This is exactly what we have now.  I brought
it up to be sure this is what we want,

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [HACKERS] Custom compression methods
Next
From: Simon Riggs
Date:
Subject: Re: VACUUM (DISABLE_PAGE_SKIPPING on)