On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote: > 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.
Ah. > > > 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. What I meant is that each time there are new ISA extensions, or differences in how relevant/significant different implementations of the same ISA implement certain instructions, and/or every time you want to add a new architecture... someone has to do a lot of very low-level work. > > > 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 Yes, I know. > hanging fruits (particularly aggregate transition functions), but > converting everything seems to hit the wrong spot in the > benefit/effort/maintainability triangle. Maybe? At least with the infrastructure in place for it someone might try it and see. Nico -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
