E.g. PostgreSQL can do that these days (not sure if it did back then): https://www.postgresql.org/docs/current/jit-reason.html
E.g. PostgreSQL can do that these days (not sure if it did back then): https://www.postgresql.org/docs/current/jit-reason.html
ALTER SYSTEM SET jit=off;
Basically a performance blackhole for more complex queries. Most OSM related projects disable it straight away as it only creates headaches.
https://github.com/osm-search/Nominatim/pull/2559 https://github.com/gravitystorm/openstreetmap-carto/blob/mas...
The performance gains are much higher if the database engine was designed to have JIT-ed execution from day one. Grafting it onto a database engine after the fact, like Postgres, is going to gain substantially less benefit than is theoretically possible. Additionally, it mostly benefits databases where query predicates have a large amount of data to process, it doesn’t do much for OLTP. But in the right system and context, large integer factor performance improvements are routinely achievable.
We live in a world where just last week Google turned off io_uring access on a pile of machines, and that's only "executing" restricted sets of operations. Executable code in kernel = big giant target painted on back.