From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Nico Williams <nico(at)cryptonector(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Doug Doole <ddoole(at)salesforce(dot)com> |
Subject: | Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT) |
Date: | 2016-12-06 20:27:51 |
Message-ID: | 20161206202751.u7ra3u2w7bdskt7x@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> A bigger concern might be interface stability. IIRC the LLVM C/C++
> interfaces are not very stable, but bitcode is.
The C API is a lot more stable than the C++ bit, that's the primary
reason I ended up using it, despite the C++ docs being better.
> > I concur with your feeling that hand-rolled JIT is right out. But
>
> Yeah, that way lies maintenance madness.
I'm not quite that sure about that. I had a lot of fun doing some
hand-rolled x86 JITing. Not that is a ward against me being mad. But
more seriously: Manually doing a JIT gives you a lot faster compilation
times, which makes JIT applicable in a lot more situations.
> > I'm not sure that whatever performance gain we might get in this
> > direction is worth the costs.
>
> Byte-/bit-coding query plans then JITting them is very likely to improve
> performance significantly.
Note that what I'm proposing is a far cry away from that - this converts
two (peformance wise two, size wise one) significant subsystems, but far
from all the executors to be JIT able. I think there's some more low
hanging fruits (particularly aggregate transition functions), but
converting everything seems to hit the wrong spot in the
benefit/effort/maintainability triangle.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-12-06 20:31:16 | Re: Compiler warnings |
Previous Message | David G. Johnston | 2016-12-06 20:27:13 | Re: Select works only when connected from login postgres |