Re: compute_query_id and pg_stat_statements

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: magnus(at)hagander(dot)net, masao(dot)fujii(at)oss(dot)nttdata(dot)com, michael(at)paquier(dot)xyz, andres(at)anarazel(dot)de, tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)alvh(dot)no-ip(dot)org, sfrost(at)snowman(dot)net, bruce(at)momjian(dot)us, myon(at)debian(dot)org, peter(dot)eisentraut(at)enterprisedb(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: compute_query_id and pg_stat_statements
Date: 2021-05-13 02:39:20
Message-ID: 20210513023920.raegzbpqpowncbot@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 13, 2021 at 11:30:56AM +0900, Kyotaro Horiguchi wrote:
> At Thu, 13 May 2021 11:26:29 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> > At Thu, 13 May 2021 10:02:45 +0800, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote in
> > > On Thu, May 13, 2021 at 10:51:52AM +0900, Kyotaro Horiguchi wrote:
> > > > At Thu, 13 May 2021 09:59:43 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> > > > > How about adding a GUC_INTERNAL "current_query_provider" or such?
> > > >
> > > > On the second thought, I wonder why we don't just call JumbleQuery in
> > > > pgss_post_parse_analyze when compute_query_id is "off".
> > >
> > > Because not generating a query_id for a custom query_id implementation is a
> > > valid use case for queries that are known to lead to huge pg_stat_statements
> > > overhead, as I mentioned in [1]. For the record I implemented that in
> > > pg_queryid (optionally don't generate query_id for queries referencing a temp
> > > relation) yesterday evening as a POC for that approach.
> >
> > Yes, I know. So I said that "if not yet called". I believe any "real"
> > alternative query-id provider is supposed to be hooked "before"
> > pg_stat_statements. (It is a kind of magic to control the order of
> > plugins, though..) When the alternative provider generated a query_id
> > (that is, it has set jstate), pg_stat_statment doesn't call the
> > in-core JumbleQuery and uses the givin query_id.
>
> Forgot to mention, I think that the state "query_id provider is active
> but it has not assigned one to this query" can be signaled by
> jstate=<non-null> and query_id = 0.

I assume that you mean "third-party query_id provider" here, as the core one
will always return a non-zero query_id?

I guess it could work, but a lot of people are complaining that having
compute_query_id = [ off | on | auto ] is too confusing, so I don't see how
having "off" means "sometimes off, sometimes on" is going to be any clearer for
users.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-05-13 02:43:03 Re: compute_query_id and pg_stat_statements
Previous Message Kyotaro Horiguchi 2021-05-13 02:30:56 Re: compute_query_id and pg_stat_statements