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

Andreas Joseph Krogh <andreas@visena.com>

From: Andreas Joseph Krogh <andreas@visena.com>
To: pgsql-hackers@lists.postgresql.org
Date: 2018-09-08T10:44:14Z
Lists: pgsql-hackers
På torsdag 23. august 2018 kl. 09:14:56, skrev Andreas Joseph Krogh <
andreas@visena.com <mailto:andreas@visena.com>>:
På torsdag 23. august 2018 kl. 03:00:42, skrev Jonathan S. Katz <
jkatz@postgresql.org <mailto:jkatz@postgresql.org>>:

 > On Aug 22, 2018, at 7:13 PM, Andres Freund <andres@anarazel.de> wrote:
 [snip]
 > For the archives sake: This likely largely is the consequence of
 > building with LLVM's expensive assertions enabled, as confirmed by
 > Jonathan over IM.

 I recompiled with the release version of LLVM. jit=on was still slower,
 but the discrepancy was not as bad as the previously reported result:

 jit = off
 Planning Time: 0.938 ms
 Execution Time: 935.599 ms

 jit = on
 Planning Time: 0.951 ms
 JIT:
   Functions: 184
   Generation Time: 17.605 ms
   Inlining: true
   Inlining Time: 20.522 ms
   Optimization: true
   Optimization Time: 1001.034 ms
   Emission Time: 665.319 ms
 Execution Time: 2491.560 ms

 However, it was still 2x+ slower, so still +1ing for open items.
 
 
I compiled with whatever switches LLVM that comes with Ubuntu 18.04 is built 
with, and without debugging or assertions.
 
With 11b3 as of 825f10fbda7a5d8a48d187b8193160e5e44e4011 I'm repeatedly 
getting these results with jit=on, after 10 runs:
 
 
 
Planning Time: 0.266 ms 
 JIT:
  Functions: 686
  Generation Time: 71.895 ms
  Inlining: false
  Inlining Time: 0.000 ms
  Optimization: false
  Optimization Time: 39.906 ms
  Emission Time: 589.944 ms
 Execution Time: 2198.928 ms
  
 
 
Turning jit=off gives this:
 
Planning Time: 0.180 ms
Execution Time: 938.451 ms
 
I can provide dataset offlist if anyone wants to look into this.
 
--
 Andreas Joseph Krogh

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.