Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id 20210513170538.GL11075@momjian.us
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Andrew Dunstan <andrew@dunslane.net>)
List 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 by date:

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