@@ -10,11 +10,11 @@ SQL expressions to evaluate an SQL predicate like WHERE a.col = 3, it
1010is possible to generate a function than can be natively executed by
1111the CPU that just handles that expression, yielding a speedup.
1212
13- That this isdone at query execution time, possibly even only in cases
14- where the relevant task is done a number of times, makes it JIT,
15- rather than ahead-of-time (AOT) . Given the way JIT compilation is used
16- in PostgreSQL, the lines between interpretation, AOT and JIT are
17- somewhat blurry.
13+ This isJIT, rather than ahead-of- time (AOT) compilation, because it
14+ is done at query execution time, and perhaps only in cases where the
15+ relevant task is repeated a number of times . Given the way JIT
16+ compilation is used in PostgreSQL, the lines between interpretation,
17+ AOT and JIT are somewhat blurry.
1818
1919Note that the interpreted program turned into a native program does
2020not necessarily have to be a program in the classical sense. E.g. it
@@ -99,7 +99,7 @@ Lifetimes of JITed functions are managed via JITContext. Exactly one
9999such context should be created for work in which all created JITed
100100function should have the same lifetime. E.g. there's exactly one
101101JITContext for each query executed, in the query's EState. Only the
102- release ofan JITContext is exposed to the provider independent
102+ release ofa JITContext is exposed to the provider independent
103103facility, as the creation of one is done on-demand by the JIT
104104implementations.
105105
@@ -231,7 +231,7 @@ needs to be referenced as an offset to one block of memory stored in
231231an ExprState, rather than absolute pointers into memory.
232232
233233Once that is addressed, adding an LRU cache that's keyed by the
234- generated LLVM IR will allowto use optimized functions even for
234+ generated LLVM IR will allowthe usage of optimized functions even for
235235faster queries.
236236
237237A longer term project is to move expression compilation to the planner