Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@lists.postgresql.org,Robert Haas <robertmhaas@gmail.com>
Cc: Andreas Joseph Krogh <andreas@visena.com>,PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-18T19:29:22Z
Lists: pgsql-hackers 

On April 18, 2018 12:16:35 PM PDT, Robert Haas <robertmhaas@gmail.com> wrote:
>On Wed, Apr 18, 2018 at 11:50 AM, Andres Freund <andres@anarazel.de>
>wrote:
>> 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.
>
>It seems like you're describing it as if the JIT just didn't produce
>gains sufficient to make up for the cost of doing it, but that's not
>really the issue here AFAICS.  Here the JIT actually made code that
>run slower than the un-JIT-ted code.  That seems like a different sort
>of problem.

Not convinced that that is true - the issue is more likely that JIT work in workers is counted as execute time... Gotta add that somehow, not sure what the best way would be.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Commits

  1. Fix issues around EXPLAIN with JIT.

  2. Collect JIT instrumentation from workers.

  3. Make EXPLAIN output for JIT compilation more dense.

  4. Save/restore SPI's global variables in SPI_connect() and SPI_finish().

  5. Rationalize handling of single and double quotes in bootstrap data.