Re: compute_query_id and pg_stat_statements

At Thu, 13 May 2021 09:59:43 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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