Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id d7a5dd14-27a9-931e-3901-02319cef669b@dunslane.net
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Re: compute_query_id and pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: compute_query_id and pg_stat_statements
Следующее
От: Justin Pryzby
Дата:
Сообщение: amvalidate(): cache lookup failed for operator class 123