Re: Query is over 2x slower with jit=on

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Query is over 2x slower with jit=on
Дата
Msg-id CANP8+jJw1e6PtVFHSwAidvifbMyG4OhhEN_Z09trAo5ChV7gVw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query is over 2x slower with jit=on  (Andres Freund <andres@anarazel.de>)
Ответы Re: Query is over 2x slower with jit=on  (Chapman Flack <chap@anastigmatix.net>)
Список 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 по дате отправления:

Предыдущее
От: Andreas Joseph Krogh
Дата:
Сообщение: Sv: Re: Query is over 2x slower with jit=on
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Deadlock in multiple CIC.