Re: Add parameter jit_warn_above_fraction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add parameter jit_warn_above_fraction
Date: 2022-03-29 22:04:32
Message-ID: 113361.1648591472@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Tue, Mar 29, 2022 at 1:06 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>> That means that even if the total execution time of a plan was a true
>> reflection of the total estimated plan cost, then the fraction of time
>> spent (as is measured by jit_warn_above_fraction) doing JIT would
>> entirely depend on the number of expressions to compile. Of course,
>> the planner's not that good, but does that not indicate that the JIT
>> costing should really account for the number of expressions and not
>> just the total plan cost?

> That's a good point.

I think David's questions are sufficiently cogent and difficult
that we should not add jit_warn_above_fraction at this time.
Maybe we'll eventually decide it's the best we can do; but I do
not think we have a problem there that's so pressing that we need
to rush out a partially-baked bandaid. Especially not at the
tail end of the development cycle, with not much time to gain
experience with it before we ship.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-03-29 22:16:15 Re: Window Function "Run Conditions"
Previous Message Andrew Dunstan 2022-03-29 21:56:02 Re: Extend compatibility of PostgreSQL::Test::Cluster