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".
We can think this behavior as the following.
- compute_query_id sets whether the *internal* query-id provider turn
on. If it is "off", query_id in , for example, pg_stat_activity is
not set. Even in that case it is set to some valid value if some
alternative query-id provider is active.
On the other hand pg_stat_statements looks as if providing
"alternative" query-id provider, but actually it is just calling
in-core JumbleQuery if not called yet.
@@ -830,6 +830,10 @@ pgss_post_parse_analyze(ParseState *pstate, Query *query, JumbleState *jstate)
return;
}
+ /* Call in-core JumbleQuery if it was not called in-core */
+ if (!jstate)
+ jstate = JumbleQuery(query, pstate->p_sourcetext);
+
/*
Any plugins that want to use its own query-id generator can WARN if
jstate is not NULL, but also can proceed ignoring the exisint jstate.
WARNING: the default query-id provier is active, turn off compute_query_id to avoid unnecessary calculation
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center