6 ms·

> There's no rarity of JITs, it's just that LLVM (and other frameworks) are often used Except that using LLVM has high latency limitting it's applicability. Po

> There's no rarity of JITs, it's just that LLVM (and other frameworks) are often used Except that using LLVM has high latency limitting it's applicability. Postgres just disabled LLVM by default because of this[0]. [0] https://www.postgresql.org/message-id/E1w8GWU-002bSL-31%40gemulon.postgresql.org https://www.postgresql.org/message-id/E1w8GWU-002bSL-31%40ge...

MaxBarraclough 24d ago
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%) [0] https://www.pinaraf.info/2025/12/jit-episode-iii-warp-speed-ahead/ https://www.pinaraf.info/2025/12/jit-episode-iii-warp-speed-...

MaxBarraclough 24d ago

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%) [0] https://www.pinaraf.info/2025/12/jit-episode-iii-warp-speed-ahead/ https://www.pinaraf.info/2025/12/jit-episode-iii-warp-speed-...