Re: compute_query_id and pg_stat_statements
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: magnus@hagander.net, masao.fujii@oss.nttdata.com, michael@paquier.xyz, andres@anarazel.de, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, sfrost@snowman.net, bruce@momjian.us, myon@debian.org, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Date: 2021-05-13T02:59:24Z
Lists: pgsql-hackers
On Thu, May 13, 2021 at 11:49:34AM +0900, Kyotaro Horiguchi wrote: > 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"? No, the consensus was for having a tristate, so I implemented it, and now people are complaining that it's too confusing. > 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". I don't see how it's really different. If I understand correctly, you're suggesting that use_internal_query_id_generator = off can mean either - off - on if pg_stat_statements or similar extension is configured but no custom query_id provider is configured, and in any case it will always be displayed as off with no other new GUC. Is that correct?
Commits
-
Allow compute_query_id to be set to 'auto' and make it default
- cafde58b337e 14.0 landed
-
Move pg_stat_statements query jumbling to core.
- 5fd9dfa5f50e 14.0 cited