Re: Query is over 2x slower with jit=on - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Query is over 2x slower with jit=on
Date
Msg-id CANP8+jJw1e6PtVFHSwAidvifbMyG4OhhEN_Z09trAo5ChV7gVw@mail.gmail.com
Whole thread Raw
In response to Re: Query is over 2x slower with jit=on  (Andres Freund <andres@anarazel.de>)
Responses Re: Query is over 2x slower with jit=on  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
On 18 April 2018 at 16:50, Andres Freund <andres@anarazel.de> wrote:
> On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote:
>> With jit=on:
>> https://explain.depesz.com/s/vYB
>> Planning Time: 0.336 ms
>>  JIT:
>>   Functions: 716
>>   Generation Time: 78.404 ms
>>   Inlining: false
>>   Inlining Time: 0.000 ms
>>   Optimization: false
>>   Optimization Time: 43.916 ms
>>   Emission Time: 600.031 ms
>
> Any chance this is a debug LLVM build?
>
>
>> What's the deal with jit making it slower?
>
> JIT has cost, and sometimes it's not beneficial. Here our heuristics
> when to JIT appear to be a bit off. In the parallel world it's worse
> because the JITing is duplicated for parallel workers atm.

Please change the name of the "JIT" parameter to something meaningful
to humans before this gets too far into the wild.

SSL is somewhat understandable because its not a Postgres-private term.

geqo is regrettable and we really don't want any more too
short/abbreviated parameter names.

Think of our EOU if every GUC was a TLA.

Thanks

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Andreas Joseph Krogh
Date:
Subject: Sv: Re: Query is over 2x slower with jit=on
Next
From: Alvaro Herrera
Date:
Subject: Re: Deadlock in multiple CIC.