The author mentions PostgreSQL's JIT compiler. Up to this day, I've only seen it degrade the performance of queries. Disabling it is on my install checklist.
Turns out homebrew installed postgres without JIT support and one query on the developer machine ran in 200ms, while with JIT the query took 4-5 seconds. Took some time to figure out, since I'm not a heavy postgres user, but since then I've always disabled JIT and never looked back.
You can configure thresholds for the JIT activation in PostgreSQL as well if you want to elevate the bar from which the JIT is enabled.
[0] https://pganalyze.com/blog/5mins-postgres-optimize-subquerie...
[1] https://duckdb.org/2023/05/26/correlated-subqueries-in-sql.h...
[2] "Unnesting Arbitrary Queries" https://cs.emis.de/LNI/Proceedings/Proceedings241/383.pdf
It would probably be less detrimental if it could perform asynchronous compilation for future queries (which really is closer to how normal JITs actually behave, at least for optimising backends)
That seems like a generalisation. It's true LLVM will never be a lightweight toolkit, but if you want to generate highly optimised code it seems like a solid choice, assuming you're doing relatively 'vanilla' code-gen work.
The inline blocking compilation step will still fuck your query.
> also add hints please
I’d much rather they allowed bypassing the planner entirely and had an interface to feed plans directly to the executor.
Only on the first execution, the long plan/jit time is usually only an issue when running a fast query over and over again.
However if plans where cached then you could also plan without jitting then background jit and update cached plan for next time which would be even smarter.
>I’d much rather they allowed bypassing the planner entirely and had an interface to feed plans directly to the executor
Other database have plan locking where you can load an existing plan from somewhere else in serialized form (XML) and force it to use that. Most of the time I prefer just a few hints in the query source solves almost all issue with the planner.