3 ms·
It should be interesting, but LLVM jit brings in a substantial up front cost. Maybe Andres found a way to mitigate it.
by fnord123 10y ago
It should be interesting, but LLVM jit brings in a substantial up front cost. Maybe Andres found a way to mitigate it.
- jordanthoms 10y agoIs it significant when you are talking about analytical queries which are running for minutes or hours? Seems like it wouldn't be a huge amount of code to JIT compared to the payoff?
- electrum 10y agoPresto, which is designed for analytics, does JIT to bytecode on every query and still works fine on sub-second queries. One potential difference with LLVM is that the JVM will profile and only generate machine code for hot code, so short queries might use JVM interpreted bytecode. But you are absolutely correct that for long running analytic queries, the up front cost of generating optimized code pays off.
- anarazel 10y agoThe plan is to just use interpretation of expressions for short-running queries. I've spent a lot of work in this release cycle making that faster, and allowing for an easier integration w/ less duplication between JIT and interpreted evaluation. There's two approaches for deciding when to JIT: a) based on query cost estimation. b) just do it after a threshold number of executions. I've not yet decided / experimented enough to make a call. Additionally, at a later stage, caching of compiled programs will play a role, to reduce the frequency of llvm invocation.