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
