Re: compute_query_id and pg_stat_statements

At Thu, 13 May 2021 10:39:20 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in 
> 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.ntt@gmail.com> wrote in 
> > > At Thu, 13 May 2021 10:02:45 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in 
> > > 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?

Right.

> 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.

I don't get it. It read as "people are complaining the tristate is too
confusing, so I made it tristate"?

For the second point, so I said that the variable controls whether the
"internal" query-id pvovider turn on.  It is more clearer if the name
were something like "use_internal_query_id_generator".

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center