Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id 20210511105249.2obdq32n6tc5gyqd@nol
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: compute_query_id and pg_stat_statements  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On Tue, May 11, 2021 at 05:41:06PM +0800, Julien Rouhaud wrote:
> On Tue, May 11, 2021 at 10:59:51AM +0200, Magnus Hagander wrote:
> > 
> > That doesn't fundamentally make it impossible, you just have to add it
> > to the list of variables being copied over, wouldn't you? See
> > save_backend_variables()
> 
> Yes, I agree, and that's what I meant by "explicitly handled".  The thing is
> that I don't know if that's the best way to go, as it doesn't solve the "is it
> actually enabled" and/or "which implementation is used".  At least the patch I
> sent, although it's totally a hack, let you know if compute_query_id is enabled
> or not.  I'm fine with implementing it that way, but only if there's a
> consensus.

Actually, isn't that how e.g. wal_buffers = -1 is working?  The original value
is lost and what you get is the computed value.  This is a bit different here
as the value isn't always changed, and can be changed interactively but
otherwise it's the same behavior.



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

Предыдущее
От: "tanghy.fnst@fujitsu.com"
Дата:
Сообщение: RE: Remove "FROM" in "DELETE FROM" when using tab-completion
Следующее
От: Joe Conway
Дата:
Сообщение: Re: PG 14 release notes, first draft