From 08909b32df28215288035cc9fb216795bb7bc042 Mon Sep 17 00:00:00 2001 From: Daniel Gustafsson Date: Thu, 31 May 2018 14:43:57 -0400 Subject: [PATCH] Minor wordsmithing on the JIT documentation --- doc/src/sgml/jit.sgml | 2 +- src/backend/jit/README | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/jit.sgml b/doc/src/sgml/jit.sgml index 6a712ff7c2..b2f0ab8bc7 100644 --- a/doc/src/sgml/jit.sgml +++ b/doc/src/sgml/jit.sgml @@ -26,7 +26,7 @@ doing so at runtime. For example, instead of using a facility that can evaluate arbitrary SQL - expressions to evaluate an SQL predicate like WHERE a.col = + expressions to evaluate a SQL predicate like WHERE a.col = 3, it is possible to generate a function than can be natively executed by the CPU that just handles that expression, yielding a speedup. diff --git a/src/backend/jit/README b/src/backend/jit/README index 6271677163..7456980df6 100644 --- a/src/backend/jit/README +++ b/src/backend/jit/README @@ -6,12 +6,12 @@ interpreted program evaluation into a native program, and doing so at runtime. For example, instead of using a facility that can evaluate arbitrary -SQL expressions to evaluate an SQL predicate like WHERE a.col = 3, it +SQL expressions to evaluate a SQL predicate like WHERE a.col = 3, it is possible to generate a function than can be natively executed by the CPU that just handles that expression, yielding a speedup. That this is done at query execution time, possibly even only in cases -the relevant task is done a number of times, makes it JIT, rather than +where the relevant task is done a number of times, makes it JIT, rather than ahead-of-time (AOT). Given the way JIT compilation is used in PostgreSQL, the lines between interpretation, AOT and JIT are somewhat blurry. @@ -231,7 +231,7 @@ needs to be referenced as an offset to one block of memory stored in an ExprState, rather than absolute pointers into memory. Once that is addressed, adding an LRU cache that's keyed by the -generated LLVM IR will allow to use optimized functions even for +generated LLVM IR will allow to use optimized functions for even faster queries. A longer term project is to move expression compilation to the planner -- 2.14.1.145.gb3622a4ee