Date: Sat, 9 Apr 2022 12:20:57 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Magnus Hagander <magnus@hagander.net>,
	David Rowley <dgrowleyml@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Andres Freund <andres@anarazel.de>,
	Justin Pryzby <pryzby@telsasoft.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Add parameter jit_warn_above_fraction
Message-ID: <YlEJqTkG9rG7OcYs@jrouhaud>
References: <20220321235048.wb3ymun6lbi33b2u@alap3.anarazel.de>
 <CABUevEy9H+HPAuM1ofC=OuY2+bESOsA4hHSAY6HbLYyTG1oaPw@mail.gmail.com>
 <20220329100846.3iedk5ear3ewdi5j@jrouhaud>
 <CA+TgmoZ-AoXM=J5J===maHDY9O+Mbz-=Sfz-A23ZbiJoMKe_Rg@mail.gmail.com>
 <CAApHDvrEoQ5p61NjDCKVgEWaH0qm1KprYw2-7m8-6ZGGJ8A2Dw@mail.gmail.com>
 <CABUevExkr8pajkKFD=OnTj3q0S0GZc-u6iqD6L0ZXjO8z3-1gQ@mail.gmail.com>
 <CABUevEw+dC=6sieitWSqqEjz8OaACOihxpWempoLewdKGnnrig@mail.gmail.com>
 <CAApHDvor25wyUUPm6vAZn8uDNaQ=15fDh+4XuBGo3-_QCmfZUg@mail.gmail.com>
 <CABUevEwT+nMj+m+=z=wPyYzq3Mh9ohuqrWBjR7q9uZawBA6j3A@mail.gmail.com>
 <20220408133918.GE10577@tamriel.snowman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220408133918.GE10577@tamriel.snowman.net>
Archived-At: 
 <https://www.postgresql.org/message-id/YlEJqTkG9rG7OcYs%40jrouhaud>
Precedence: bulk

Hi,

On Fri, Apr 08, 2022 at 09:39:18AM -0400, Stephen Frost wrote:
>
> * Magnus Hagander (magnus@hagander.net) wrote:
> > The addition to pg_stat_statements I pushed a short while ago would help
> > with that. But I think having a warning like this would also be useful. As
> > a stop-gap measure, yes, but we really don't know when we will have an
> > improved costing model for it. I hope you're right and that we can have it
> > by 16, and then I will definitely advocate for removing the warning again
> > if it works.
>
> 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.