Interesting, thanks for the link. LLVM isn't the only game in town though, nobody using it (or libgccjit) for JIT should be surprised to see relatively long compile times. I wonder if the postgres project will try a different backend.

There's a strong 'diminishing returns' effect in striking a balance between compile time and the performance of the generated code. I'd expect a more lightweight (less optimising) JIT engine to be able to produce code with pretty respectable performance while taking only a fraction of the time that LLVM takes. There's a follow-up to the blog post I linked above, which bears this out. [0] (I don't know if that JIT solution is production-ready or viable for merging into postgres, mind.)

The blog post [0] gives this performance comparison:

> So, on our stupid benchmark, doing 10 times a simple SELECT * FROM demo WHERE a = 42 on a 10 million rows table...

    PostgreSQL             No JIT          LLVM JIT               Copyjit
    ----------             ------          --------               -------
    Average time (ms)      120             106 (-12%)             101 (-15%)
    Compilation time (ms)  0               19                     0.06
    Instructions           13,350,766,209  10,643,820,667 (-21%)  12,769,013,536 (-5%)
    Cycles                 4,660,821,596   4,005,881,863 (-14%)   3,924,602,439 (-16%)
    Branches               2,322,470,659   1,798,221,785 (-23%)   2,031,456,214 (-13%)