Re: Defaulting to jit=on/off for v11 - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: Defaulting to jit=on/off for v11
Date
Msg-id b805311e-c177-da92-43fa-748e93b120b7@postgresql.org
Whole thread Raw
In response to Re: Defaulting to jit=on/off for v11  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 9/14/18 6:32 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I can see basically three sensible routes to go for v11 (before we
>> improve further):
>
>> 1) Leave it enabled, as currently.
>
>> 2) Disable it by default in v11, leave it enabled in master.
>
>> 3) Increase the costs substantially, so it triggers in far fewer
>>    cases. Those would be too high for cases that want to benefit fully,
>>    but would reduce the risk - although it also probably makes it
>>    harder to easily hit problematic cases.
>
> I'd go with #2, personally.  It does seem that the costing needs work,
> but it's not clear to me that we know what to change, so it's kinda
> late to propose #3 for v11.

First, I'm going to say I'm a huge fan of this feature and I'm excited
for the ongoing work.

From doing some testing, I hit a substantial performance loss on a query
that would be considered part of the critical path of a system. I'm sure
getting the costing right would help, but also that query did contain
expressions that could benefit from JIT compilation. My concern would be
 that other apps have queries that would make them start to under perform.

The nice thing is you can enable jit on a per query basis if needed -
more work for the user, but I think safer in the first release than
having it on by default.

+1 to option #2.

Jonathan


Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: move PartitionDispatchData definition to execPartition.c
Next
From: Peter Geoghegan
Date:
Subject: Re: Defaulting to jit=on/off for v11