Re: compute_query_id and pg_stat_statements

Hello Horiguchi-san,

On Wed, May 12, 2021 at 11:08:36AM +0900, Kyotaro Horiguchi wrote:
>
> If we look it in pg_settings, it shows the current value and the value
> at boot-time. So I'm fine with that behavior.
>
> However, IMHO, I doubt the necessity of "on". Assuming that we require
> any module that wants query-id to call queryIdWanted() at any time
> after each process startup (or it could be inherited to children), I
> think only "auto" and "off" are enough for the variable.

I don't think that this approach would cope well for people who want a queryid
without pg_stat_statements or such. Since the queryid can now be found in
pg_stat_activity, EXPLAIN output or the logs I think it's entirely reasonable
to allow users to benefit from that even if they don't install additional
module.

> Thinking in
> this line, the variable is a subset of a GUC variable to specify the
> name of a query-id provider (as Andres suggested upthread), and I
> think it would work better in future.
>
> So for now I propose that we have a variable query_id_provider that
> has only 'default' and 'none' as the domain.

I think this would be a mistake to do that, as it would mean that we don't
officially support alternative queryid provider.

> We can later expand it
> so that any other query-id provider modules can be loaded without
> chaning the interface.

The GUC itself may not change, but third-party queryid provider would probably
need changes as the new entry point will be dedicated to compute a queryid
only, while third-party plugins may do more than that in their
post_parse_analyze_hook. And also users will have to change their
configuration to use that new interface, and additionally the module may now
have to be removed from shared_preload_libraries. Overall, it doesn't seem to
me that it would make users' life easier.