Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id 20210513170538.GL11075@momjian.us
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Thu, May 13, 2021 at 12:45:07PM -0400, Andrew Dunstan wrote:
> 
> 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.

The issue is that there is no external way to check what query id
computation is being used, unlike huge pages, which can be queried from
the operating system.  I also agree it is late, and discussion of auto
continues to show cases where this makes later improvements more
complex.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




В списке pgsql-hackers по дате отправления:

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