From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: effect of JIT tuple deform? |
Date: | 2018-06-24 20:36:33 |
Message-ID: | 20180624203633.uxirvmigzdhcyjsd@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-06-24 22:32:07 +0200, Dmitry Dolgov wrote:
> `perf diff` indeed shows that in the first case (with the 4M rows dataset) the
> jitted version has some noticeable delta for one call, and unfortunately so far
> I couldn't figure out which one exactly because of JIT (btw, who can explain
> how to see a correct full `perf report` in this case? Somehow `perf
> inject --jit -o
> perf.data.jitted` and jit_profiling_support didn't help).
jit_profiling_support currently requires a patch (that I'm about to
merge into their trunk) in LLVM. I've posted it a couple times to the
list.
> But since on the bigger dataset I've got expected results, maybe it's just a
> sign that JIT kicks in too early in this case and what's necessary is to adjust
> jit_above_cost/jit_optimize_above_cost/jit_inline_above_cost?
Yea, that's very likely the problem. I wonder if we should multiply the
cost w/ the number of targeted workers to reduce problems with
parallelism...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2018-06-24 21:13:38 | do I correctly understand these date/time data types? |
Previous Message | Dmitry Dolgov | 2018-06-24 20:32:07 | Re: effect of JIT tuple deform? |