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

From: Andreas Joseph Krogh <andreas(at)visena(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Sv: Re: Query is over 2x slower with jit=on
Date: 2018-09-08 10:44:14
Message-ID: VisenaEmail.6.ca44a189d8b47f10.165b8a8b449@tc7-visena
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

På torsdag 23. august 2018 kl. 09:14:56, skrev Andreas Joseph Krogh <
andreas(at)visena(dot)com <mailto:andreas(at)visena(dot)com>>:
På torsdag 23. august 2018 kl. 03:00:42, skrev Jonathan S. Katz <
jkatz(at)postgresql(dot)org <mailto:jkatz(at)postgresql(dot)org>>:

> On Aug 22, 2018, at 7:13 PM, Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2018-09-08 12:52:40 Re: StandbyAcquireAccessExclusiveLock doesn't necessarily
Previous Message Jinhua Luo 2018-09-08 09:41:06 How to find local logical replication origin?