From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: Andres Freund <andres@anarazel.de>, 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
In-reply-to: 
 <CAApHDvov2Zknd6KOT07YBOG1qGd4DCapAJ48gpa0161R7Sbc_g@mail.gmail.com>
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>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Wed, 30 Mar 2022 12:41:41 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <121715.1648597701.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Mar 2022 19:48:21 -0400
Message-ID: <121716.1648597701@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/121716.1648597701%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 30 Mar 2022 at 12:16, Andres Freund <andres@anarazel.de> wrote:
>> 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 wher=
e 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.

As long as you don't need the info till the end of planning, it should be
reasonably simple to determine.  I'm not sure if we actually record the
expected number of loops in the plan tree today, but the costing
mechanisms certainly estimate that along the way, so we could store it
if need be.

			regards, tom lane