On Tue, Dec 06, 2016 at 01:56:28PM -0500, Tom Lane wrote:
> Andres Freund <andres@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
--
