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