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