Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id d7a5dd14-27a9-931e-3901-02319cef669b@dunslane.net
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: compute_query_id and pg_stat_statements
Re: compute_query_id and pg_stat_statements
List pgsql-hackers
On 5/13/21 12:18 AM, Fujii Masao wrote:
>
>
>
> 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.
>
>

Not a bad analogy, showing there's some precedent for this sort of thing.


The only thing that bugs me is that we're pretty damn late in the
process to be engaging in this amount of design.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: compute_query_id and pg_stat_statements
Next
From: Justin Pryzby
Date:
Subject: amvalidate(): cache lookup failed for operator class 123