Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id 20210514172838.GG22344@momjian.us
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: compute_query_id and pg_stat_statements  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Fri, May 14, 2021 at 12:21:23PM -0400, Bruce Momjian wrote:
> On Fri, May 14, 2021 at 12:04:05PM -0400, Andrew Dunstan wrote:
> > > On May 14, 2021, at 8:35 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > > 
> > > On Thu, May 13, 2021 at 09:41:42PM -0400, Bruce Momjian wrote:
> > > I think keeping the output as 'auto', and documenting that this query
> > > must be run to determine if the query id is being computed:
> > > 
> > >    SELECT query_id
> > >    FROM pg_stat_activity
> > >    WHERE pid = pg_backend_pid();
> > > 
> > > is the right approach.
> > 
> > I’d rather we added a specific function. This is not really obvious.
> 
> Well, we can document this query, add a function, or add a read-only
> GUC.  I am not sure how we decide which one to use.

I wonder if we should go with an SQL query now (no new API needed) and
then add a GUC once we decide on how extensions can register that they
are generating the query id, so the GUC can report the generating
source, not just a boolean.  The core server can also register as the
source.

-- 
  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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pgsql: autovacuum: handle analyze for partitioned tables
Следующее
От: vignesh C
Дата:
Сообщение: Re: alter subscription drop publication fixes