Re: compute_query_id and pg_stat_statements

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