On Sat, Jan 27, 2018 at 5:15 PM, Andres Freund <and...@anarazel.de> wrote:
>> Also, I'm sure you considered this, but I'd like to ask if we can try
>> harder make the JIT itself happen in an extension. It has some pretty
>> huge benefits:
>
> I'm very strongly against this. To the point that I'll not pursue JITing
> further if that becomes a requirement.
I would like to see this feature succeed and I'm not making any
specific demands.
> infeasible because quite freuquently both non-JITed code and JITed code
> need adjustments. That'd solve your concern about
Can you explain further?
> I think it's a fools errand to try to keep in sync with core changes on
> the expression evaluation and struct definition side of things. There's
> planner integration, error handling integration and similar related
> things too, all of which require core changes. Therefore I don't think
> there's a reasonable chance of success of doing this outside of core
> postgres.
I wasn't suggesting the entire patch be done outside of core. Core
will certainly need to know about JIT compilation, but I am not
convinced that it needs to know about the details of LLVM. All the
references to the LLVM library itself are contained in a few files, so
you've already got it well organized. What's stopping us from putting
that code into a "jit provider" extension that implements the proper
interfaces?
> Well, but doing this outside of core would pretty much prohibit doing so
> forever, no?
First of all, building .bc files at build time is much less invasive
than linking to the LLVM library. Any version of clang will produce
bitcode that can be read by any LLVM library or tool later (more or
less).
Second, we could change our minds later. Mark any extension APIs as
experimental, and decide we want to move LLVM into postgres whenever
it is needed.
Third, there's lots of cool stuff we can do here:
* put the source in the catalog
* an extension could have its own catalog and build the source into
bitcode and cache it there
* the source for functions would flow to replicas, etc.
* security-conscious environments might even choose to run some of
the C code in a safe C interpreter rather than machine code
So I really don't see this as permanently closing off our options.
Regards,
Jeff Davis
