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
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 |