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

From Andreas Joseph Krogh
Subject Sv: Re: Query is over 2x slower with jit=on
Date
Msg-id VisenaEmail.6.ca44a189d8b47f10.165b8a8b449@tc7-visena
Whole thread Raw
In response to Re: Query is over 2x slower with jit=on  (Andreas Joseph Krogh <andreas@visena.com>)
List pgsql-hackers
På torsdag 23. august 2018 kl. 09:14:56, skrev Andreas Joseph Krogh <andreas@visena.com>:
På torsdag 23. august 2018 kl. 03:00:42, skrev Jonathan S. Katz <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

pgsql-hackers by date:

Previous
From: Jinhua Luo
Date:
Subject: How to find local logical replication origin?
Next
From: Simon Riggs
Date:
Subject: Re: StandbyAcquireAccessExclusiveLock doesn't necessarily