Date: Tue, 29 Mar 2022 17:20:30 -0700
From: Andres Freund <andres@anarazel.de>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Julien Rouhaud <rjuju123@gmail.com>,
	Magnus Hagander <magnus@hagander.net>,
	Justin Pryzby <pryzby@telsasoft.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Add parameter jit_warn_above_fraction
Message-ID: <20220330002030.fdfopirlsakhsg77@alap3.anarazel.de>
References: 
 <CABUevExR_9ZmkYj-aBvDreDKUinWLBBpORcmTbuPdNb5vGOLtA@mail.gmail.com>
 <20220225162304.GD9008@telsasoft.com>
 <CABUevExe1fV0RzjA7vQRp_WkjtTVF1O9E5STKodWa2CmpFoqHA@mail.gmail.com>
 <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>
 <20220329231641.ai3qrzpdo2vqvwix@alap3.anarazel.de>
 <CAApHDvov2Zknd6KOT07YBOG1qGd4DCapAJ48gpa0161R7Sbc_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAApHDvov2Zknd6KOT07YBOG1qGd4DCapAJ48gpa0161R7Sbc_g@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20220330002030.fdfopirlsakhsg77%40alap3.anarazel.de>
Precedence: bulk

Hi,

On 2022-03-30 12:41:41 +1300, David Rowley wrote:
> On Wed, 30 Mar 2022 at 12:16, Andres Freund <andres@anarazel.de> wrote:
> > > I did propose a patch to address this in [1]. It does need more work
> > > and I do plan to come back to it for v16.
> >
> > FWIW, that doesn't seem quite right - won't it stop JITing e.g. on the inner
> > side of a nested loop, just because it's cheap, even though that's where the
> > bulk of the benefits comes from?
>
> Yeah, I think the total cost would need to be multiplied by the number
> of times we expect to call that part of the plan.  I've not yet sat
> down to figure out if that's easy/cheap or hard/costly information to
> obtain.

I wonder whether it'd make sense to combine that with awareness of a few plan
types that can lead to large portions of child nodes never being executed. One
the case where the current behaviour is the worst is runtime partition pruning
in append - we compile expressions for whole subtrees that will never be
executed. We should be much more hesitant to compile there compared to a
cheap-ish node that we know will be executed as part of a large expensive part
of the plan tree.

- Andres