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
> > 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.ntt@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.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center