Re: JIT compiling with LLVM v11 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: JIT compiling with LLVM v11
Date
Msg-id 98869aa9-0ffc-530b-2b28-6de6625a45b7@2ndquadrant.com
Whole thread Raw
In response to Re: JIT compiling with LLVM v11  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: JIT compiling with LLVM v11  (Andres Freund <andres@anarazel.de>)
Re: JIT compiling with LLVM v11  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 3/6/18 10:29, Peter Eisentraut wrote:
> I think taking the total cost as the triggering threshold is probably
> good enough for a start.  The cost modeling can be refined over time.

I looked into this a bit more.

The default of jit_above_cost = 500000 seems pretty good.  I constructed
a query that cost about 450000 where the run time with and without JIT
were about even.  This is obviously very limited testing, but it's a
good start.

For jit_optimize_above_cost, in my testing, any query where JIT payed
off was even faster with optimizing.  So right now I don't see a need to
make this a separate setting.  Maybe just make it an on/off setting for
experimenting.

For inlining, I haven't been able to get a clear picture.  It's a bit
faster perhaps, but the optimizing dominates it.  I don't have a clear
mental model for what kind of returns to expect from this.

What I'd quite like is if EXPLAIN or EXPLAIN ANALYZE showed something
about what kind of JIT processing was done, if any, to help with this
kind of testing.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: FOR EACH ROW triggers on partitioned tables
Next
From: Andres Freund
Date:
Subject: Re: JIT compiling with LLVM v11