Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
От | Andres Freund |
---|---|
Тема | Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT) |
Дата | |
Msg-id | 20161206202751.u7ra3u2w7bdskt7x@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT) (Nico Williams <nico@cryptonector.com>) |
Ответы |
Re: WIP: Faster Expression Processing and Tuple Deforming
(including JIT)
|
Список | 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
В списке pgsql-hackers по дате отправления: