Re: compute_query_id and pg_stat_statements

On Tue, May 11, 2021 at 05:41:53PM +0900, Fujii Masao wrote:
>
> On 2021/05/11 16:35, Julien Rouhaud wrote:
> > Anyway, PFA a patch that implement a [off | on | auto] compute_query_id, and
> > provides a new queryIdWanted() function to let third party plugins inform us
> > that they want a query id if possible.
>
> Thanks!
>
>
> > As it was noted somewhere in that thread, that's a hack on top on the GUC
> > machinery, so compute_query_id will display "on" rather than "auto" (or "auto
> > and enabled" or whatever) since GUC isn't designed to handle that behavior.
>
> Can't we work around this issue by making queryIdWanted() set another flag like query_id_wanted instead of overwriting compute_query_id? If we do this, query id computation is necessary when "compute_query_id == COMPUTE_QUERY_ID_ON || (compute_query_id == COMPUTE_QUERY_ID_AUTO && query_id_wanted)".

That's exactly what Magnus mentioned :) It's not possible because variable
aren't inherited on Windows or EXEC_BACKEND. I didn't check but I'm
assuming that it could work if the other flag was an internal GUC that couldn't
be set by users, but then we would have some kind of internal flag that would
have to be documented as "how to check if compute_query_id" is actually enabled
or not, which doesn't seem like a good idea.

Another approach would be to add a new "auto (enabled)" option to the enum, and
prevent users from manually setting the guc to that value. It's not perfect
but maybe it would be cleaner.

Overall it seems that we don't have a clear consensus on how exactly to address
the problem, which is why I originally didn't sent a patch.