@@ -74,7 +74,7 @@ the shared library providing JIT support can be loaded (i.e. postgres
74
74
was compiled with LLVM support and the shared library is installed),
75
75
the task of JIT compiling an expression gets handed of to shared
76
76
library. This obviously requires that the function in jit.c is allowed
77
- to fail in case not JIT provider can be loaded.
77
+ to fail in case no JIT provider can be loaded.
78
78
79
79
Which shared library is loaded is determined by the jit_provider GUC,
80
80
defaulting to "llvmjit".
@@ -174,7 +174,7 @@ least a few postgres types. While it is possible to inform LLVM about
174
174
type definitions by recreating them manually in C code, that is failure
175
175
prone and labor intensive.
176
176
177
- Instead the is one small file (llvmjit_types.c) which references each of
177
+ Instead there is one small file (llvmjit_types.c) which references each of
178
178
the types required for JITing. That file is translated to bitcode at
179
179
compile time, and loaded when LLVM is initialized in a backend.
180
180
@@ -232,10 +232,16 @@ an ExprState, rather than absolute pointers into memory.
232
232
233
233
Once that is addressed, adding an LRU cache that's keyed by the
234
234
generated LLVM IR will allow to use optimized functions even for
235
- shorter functions .
235
+ faster queries .
236
236
237
237
A longer term project is to move expression compilation to the planner
238
- stage, allowing to tie
238
+ stage, allowing e.g. to tie compiled expressions to prepared
239
+ statements.
240
+
241
+ An even more advanced approach would be to use JIT with few
242
+ optimizations initially, and build an optimized version in the
243
+ background. But that's even further off.
244
+
239
245
240
246
What to JIT
241
247
===========
0 commit comments