5 ms·

Yeah pg’s JIT is a pretty good demonstration that LLVM is not great at JITs, worsened by postgres not having a good persistent shared query cache. It would pro

Yeah pg’s JIT is a pretty good demonstration that LLVM is not great at JITs, worsened by postgres not having a good persistent shared query cache. 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)

MaxBarraclough 3y ago
> LLVM is not great at JITs 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.
SigmundA 3y ago
PG just needs to do like the other databases and cache query plans, also add hints please.
- masklinn 3y ago
  > PG just needs to do like the other databases and cache query plans 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.
  - SigmundA 3y ago
    >The inline blocking compilation step will still fuck your query 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.
  - RMarcus 3y ago
    PostgreSQL has coarse-grain query hints (like `enable_hashjoin`), and the excellent `pg_hint_plan` extension allows you to specify a complete or partial execution plan: https://github.com/ossc-db/pg_hint_plan https://github.com/ossc-db/pg_hint_plan

MaxBarraclough 3y ago

> LLVM is not great at JITs 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.

SigmundA 3y ago

PG just needs to do like the other databases and cache query plans, also add hints please.

masklinn 3y ago
> PG just needs to do like the other databases and cache query plans 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.
- SigmundA 3y ago
  >The inline blocking compilation step will still fuck your query 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.
- RMarcus 3y ago
  PostgreSQL has coarse-grain query hints (like `enable_hashjoin`), and the excellent `pg_hint_plan` extension allows you to specify a complete or partial execution plan: https://github.com/ossc-db/pg_hint_plan https://github.com/ossc-db/pg_hint_plan