Andres Freund writes:
> On 2016-07-14 23:03:10 +0200, Andreas Seltenreich wrote:
>> That's the plan, yes. I'm sorry there's no publishable code yet on the
>> the postgres side of things. Using libFirm[1], the plan is to.
>
> Why libfirm?
- It has a more modern IR than LLVM (they're catching up though)
- It's very lightweight, compiles faster than LLVM's ./configure run
- I do have lots of experience with it and a committer bit
> It seems to only have x86 and sparc backends, and no windows support?
Ack, it's mostly used in research projects, that's why the number of
supported ISAs is small. It's enough to answer the burning question
what speedup is to expected by jit-compiling things in the backend
though. Also, if this thing actually takes off, adding more backends is
something that is easier with libFirm than LLVM, IMHO.
>> 1. Automatically generate Firm-IR for the static C code around
>> expression evaluation as well operators in the system catalog.
>
>> 2. Construct IR for expression trees (essentially all the function calls
>> the executor would do).
>
> But that essentially means redoing most of execQual's current code in IR
> - or do you want to do that via 1) above?
Manually re-doing backend logic in IR is a can of worms I do not want to
open. This would guarantee bugs and result in a maintenance nightmare,
so doing 1) for the code is the only option when something turns out to
be a bottleneck IMHO.
> As long as the preparation code (which is currently intermixed with
> the execution phase) isn't separated, that means pulling essentially
> the whole backend given that we do catalog lookups and everything
> during that phase.
Right, the catalog lookups need to be done before JIT-compilation to
allow inlining operators.
>> Currently, a student at credativ is working on applying these
>> techniques to postgres.
>
> Are you planning to support this to postgres proper?
The goal is to publish it as an extension that sneaks into planner_hook.
I think BSD-licensing is ok as long as libfirm (LGPL) is kept as an
external dependency.
regards,
Andreas