Re: Add parameter jit_warn_above_fraction
От | Tom Lane |
---|---|
Тема | Re: Add parameter jit_warn_above_fraction |
Дата | |
Msg-id | 4106296.1649515332@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add parameter jit_warn_above_fraction (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Add parameter jit_warn_above_fraction
|
Список | pgsql-hackers |
Julien Rouhaud <rjuju123@gmail.com> writes: > On Fri, Apr 08, 2022 at 09:39:18AM -0400, Stephen Frost wrote: >> Having this in pg_stat_statements is certainly helpful but having a >> warning also is. I don't think we have to address this in only one way. >> A lot faster to flip this guc and then look in the logs on a busy system >> than to install pg_stat_statements, restart the cluster once you get >> permission to do so, and then query it. > +1, especially if you otherwise don't really need or want to have > pg_stat_statements enabled, as it's far from being free. Sure you could enable > it by default with pg_stat_statements.track = none, but that seems a lot more > troublesome than just dynamically enabling a GUC, possibly for a short time > and/or for a specific database/role. The arguments against the GUC were not about whether it's convenient. They were about whether the information it gives you is actually going to be of any use. Also, good luck with "looking in the logs", because by default WARNING-level messages don't go to the postmaster log. If that's the intended use-case then the message ought to appear at LOG level (which'd also change the desirable name for the GUC). regards, tom lane
В списке pgsql-hackers по дате отправления: