Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id CAOBaU_aQHRMrY2SmFDSB2bHVo9_BaCDAr_0TZNFeNiZW4LPLSA@mail.gmail.com
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
Le jeu. 13 mai 2021 à 12:18, Fujii Masao <masao.fujii@oss.nttdata.com> a écrit :

I like leaving compute_query_id=auto instead of overwriting it to "on",
even when queryIsWanted() is called, as I told upthread. Then we can decide
that query id computation is necessary when compute_query_id=auto and
the special flag is enabled by queryIsWanted(). Of course as you and Magnus
discussed upthread, the issue in EXEC_BACKEND case should be fixed,
maybe by using save_backend_variables() or something, though.

If we do this, compute_query_id=auto seems to be similar to huge_pages=try.
When huge_pages=try, whether huge pages is actually used is defined depending
outside PostgreSQL (i.e, OS setting in this case). Neither pg_settings.setting nor
souce are not changed in that case.

I'm fine with that, but a lot of people complained that it wasn't good because you don't really know if it's actually on or not. I personally don't think that it's an issue, because what user want is to automagumically do what they want, not check how the magic happened, and if they want a third party implementation then the module can error out if the setting is on, so the burden will only be for those users, and handled by the third party module author. 

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: compute_query_id and pg_stat_statements