From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: JIT compiling with LLVM v9.0 |
Date: | 2018-01-26 08:23:41 |
Message-ID: | 20180126082340.cy42v56rwuboe5wv@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Thanks for testing things out!
On 2018-01-26 10:44:24 +0300, Konstantin Knizhnik wrote:
> Also I noticed that parallel execution didsables JIT.
Oh, oops, I broke that recently by moving where the decisition about
whether to jit or not is. There actually is JITing, but only in the
leader.
> Are there any principle problems with combining JIT and parallel execution?
No, there's not, I just need to send down the flag to JIT down to the
workers. Will look at it tomorrow. If you want to measure / play around
till then you can manually hack the PGJIT_* checks in execExprCompile.c
with that done, on my laptop, tpch-Q01, scale 10:
SET max_parallel_workers_per_gather=0; SET jit_expressions = 1;
15145.508 ms
SET max_parallel_workers_per_gather=0; SET jit_expressions = 0;
23808.809 ms
SET max_parallel_workers_per_gather=4; SET jit_expressions = 1;
4775.170 ms
SET max_parallel_workers_per_gather=4; SET jit_expressions = 0;
7173.483 ms
(that's with inlining and deforming enabled too)
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-01-26 09:17:41 | Re: [HACKERS] path toward faster partition pruning |
Previous Message | Michael Paquier | 2018-01-26 08:00:26 | Rewriting the test of pg_upgrade as a TAP test - take two |