|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Jeff Janes <jeff(dot)janes(at)gmail(dot)com>|
|Subject:||Re: Default JIT setting in V12|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2019-09-04 09:56:28 -0400, Jeff Janes wrote:
> I think it is intuitive, and with empirical evidence, that we do not want
> to JIT compile at all unless we are going to optimize the compiled code.
There's pretty clear counter-evidence however as well :(
I think it's probably more sensible to use some cheap minimal
optimization for the "unoptimized" mode - because there's some
non-linear cost algorithms with full optimizations enabled.
How does your example look with something like:
diff --git i/src/backend/jit/llvm/llvmjit.c w/src/backend/jit/llvm/llvmjit.c
index 82c4afb7011..85ddae2ea2b 100644
@@ -428,7 +428,7 @@ llvm_optimize_module(LLVMJitContext *context, LLVMModuleRef module)
if (context->base.flags & PGJIT_OPT3)
compile_optlevel = 3;
- compile_optlevel = 0;
+ compile_optlevel = 1;
* Have to create a new pass manager builder every pass through, as the
which I think - but I'd have to check - doesn't include any of the
non-linear cost optimizations.
> Is there a rationale for, or other examples to show, that it makes sense
> for the default value of jit_optimize_above_cost to be 5 fold higher than
> the default setting of jit_above_cost?
Yes. IIRC even tpc-h or something shows that with small scale one does
get noticable - but not crazy - speedups with unoptimized code, but that
it's a loss with optimized code.
|Next Message||Tom Lane||2019-09-04 14:59:25||Re: Unexpected "shared memory block is still in use"|
|Previous Message||fn ln||2019-09-04 14:49:46||Re: BUG #15977: Inconsistent behavior in chained transactions|