On Tue, Dec 06, 2016 at 01:56:28PM -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I'm posting a quite massive series of WIP patches here, to get some > > feedback. > > I guess the $64 question that has to be addressed here is whether we're > prepared to accept LLVM as a run-time dependency. There are some reasons > why we might not be: > > * The sheer mass of the dependency. What's the installed footprint of > LLVM, versus a Postgres server? How hard is it to install from source?
As long as it's optional, does this matter? A bigger concern might be interface stability. IIRC the LLVM C/C++ interfaces are not very stable, but bitcode is. > * How will we answer people who say they can't accept having a compiler > installed on their production boxes for security reasons? You don't need the front-ends (e.g., clang) installed in order to JIT. > * Are there any currently-interesting platforms that LLVM doesn't work > for? (I'm worried about RISC-V as much as legacy systems.) The *BSDs support more platforms than LLVM does, that's for sure. (NetBSD supports four more, IIRC, including ia64.) But the patches make LLVM optional anyways, so this should be a non-issue. > I concur with your feeling that hand-rolled JIT is right out. But Yeah, that way lies maintenance madness. > 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. Whether you want the maintenance overhead is another story. Sometimes byte-coding + interpretation yields a significant improvement by reducing cache pressure on the icache and the size of the program to be interpreted. Having the option to JIT or not JIT might be useful. Nico -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
