Re: Defaulting to jit=on/off for v11

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Defaulting to jit=on/off for v11
Date: 2018-09-14 22:47:56
Message-ID: b805311e-c177-da92-43fa-748e93b120b7@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/14/18 6:32 PM, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-09-14 22:49:39 Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi
Previous Message Alvaro Herrera 2018-09-14 22:37:40 Re: move PartitionDispatchData definition to execPartition.c