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 |
Date: | 2018-03-09 21:08:36 |
Message-ID: | 20180309210836.fzzkbk3oqwjr5ozr@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> experimenting.
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
that...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
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 |