|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: JIT compiling with LLVM v11|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2018-03-09 15:42:24 -0500, Peter Eisentraut wrote:
> 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
I'd prefer to be more defensive here. The time needed for JITing without
optimization is roughly linear, whereas optimization is definitely not
linear with input size.
> 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.
Yea, you need longrunning queries to benefit significantly. There's a
*lot* more potential once some structural issues with the expression
format (both with and without JIT) are fixed.
> 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.
Yea, I like that. I think we can only show that when timing is on,
because otherwise the tests will not be stable depending on --with-jit
being specified or not.
So I'm thinking of displaying it similar to the "Planning time" piece,
i.e. depending on es->summary being enabled. It'd be good to display the
inline/optimize/emit times too. I think we can just store it in the
JitContext. But the inline/optimize/emission times will only be
meaningful when the query is actually executed, I don't see a way around
|Next Message||Michael Banck||2018-03-09 21:35:33||Re: [PATCH] Verify Checksums during Basebackups|
|Previous Message||Alvaro Herrera||2018-03-09 21:05:14||Re: FOR EACH ROW triggers on partitioned tables|