Re: Add parameter jit_warn_above_fraction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add parameter jit_warn_above_fraction
Date
Msg-id 121716.1648597701@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add parameter jit_warn_above_fraction  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
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 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.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Next
From: Greg Stark
Date:
Subject: Re: Temporary tables versus wraparound... again