diff --git a/doc/src/sgml/acronyms.sgml b/doc/src/sgml/acronyms.sgml
index 5ad81a4ff77..638ffc9fe83 100644
--- a/doc/src/sgml/acronyms.sgml
+++ b/doc/src/sgml/acronyms.sgml
@@ -373,8 +373,8 @@
JIT
- Just in Time
- Compilation
+ Just-in-Time
+ compilation
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index b45c9bc592f..8025b319597 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4057,7 +4057,7 @@ ANY num_sync (
+
jit_above_cost (floating point)
jit_above_cost configuration parameter
@@ -4065,7 +4065,7 @@ ANY num_sync ( ). Performing
JIT costs time but can accelerate query execution.
@@ -4082,7 +4082,7 @@ ANY num_sync ( ) are optimized. Optimization initially
takes time, but can improve execution speed. It is not meaningful to
set this to a lower value than .
@@ -4100,7 +4100,7 @@ ANY num_sync ( ) attempt to inline functions and
operators. Inlining initially takes time, but can improve execution
speed. It is unlikely to be beneficial to set
@@ -7419,9 +7419,9 @@ SET XML OPTION { DOCUMENT | CONTENT };
If set to a non-existent library JIT will not
- available, but no error will be raised. This allows to install JIT
- support separately from the main PostgreSQL
- package.
+ available, but no error will be raised. This allows JIT support to be
+ installed separately from the main
+ PostgreSQL package.
This parameter can only be set at server start.
@@ -8702,7 +8702,7 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
Writes the generated LLVM IR out to the
filesystem, inside . This is only
- useful for development of JIT.
+ useful for working on the internals of the JIT implementation.
The default setting is off, and it can only be
changed by a superuser.
diff --git a/doc/src/sgml/jit.sgml b/doc/src/sgml/jit.sgml
index be3415fa6ce..7169744d4f9 100644
--- a/doc/src/sgml/jit.sgml
+++ b/doc/src/sgml/jit.sgml
@@ -1,31 +1,31 @@
- Just in Time Compilation (JIT)
+ Just-in-Time Compilation (JIT)
JIT
- Just In Time Compilation
+ Just-In-Time compilation
JIT
- This chapter explains what Just in Time Compilation is, and how it can be
+ This chapter explains what just-in-time compilation is, and how it can be
configured in PostgreSQL.
- What is JIT
+ What is JIT?
- Just in Time Compilation (JIT) is the process of turning
+ Just-in-time compilation (JIT) is the process of turning
some form of interpreted program evaluation into a native program, and
doing so at runtime.
- E.g. instead of using a facility that can evaluate arbitrary arbitrary SQL
+ For example, instead of using a facility that can evaluate arbitrary SQL
expressions to evaluate an 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.
@@ -43,7 +43,7 @@
- JIT accelerated operations
+ JIT Accelerated Operations
Currently PostgreSQL's JIT implementation has
support for accelerating expression evaluation and tuple deforming.
@@ -52,13 +52,13 @@
Expression evaluation is used to evaluate WHERE
clauses, target lists, aggregates and projections. It can be accelerated
- by generating code specific to the used expression.
+ by generating code specific to each case.
Tuple deforming is the process of transforming an on-disk tuple (see ) into its in-memory representation. It can be
accelerated by creating a function specific to the table layout and the
- number of to be extracted columns.
+ number of columns to be extracted.
@@ -67,7 +67,7 @@
LLVM has support for optimizing generated
code. Some of the optimizations are cheap enough to be performed whenever
- JIT is used, others are only beneficial for more longer
+ JIT is used, while others are only beneficial for longer
running queries.
See for
@@ -78,14 +78,14 @@
Inlining
- PostgreSQL is very extensible and allows to
- extend the set of datatypes, functions, operators, etc.; see . In fact the builtin ones are implemented using nearly
+ PostgreSQL is very extensible and allows new
+ datatypes, functions, operators and other database objects to be defined; see . In fact the built-in ones are implemented using nearly
the same mechanisms. This extensibility implies some overhead, e.g. due
to function calls (see ). To reduce that overhead
JIT compilation can inline the body for small functions
- into the expression using them. That allows to optimize away a significant
- percentage of the overhead.
+ into the expression using them. That allows a significant percentage of
+ the overhead to be optimized away.
@@ -95,7 +95,7 @@
When to JIT
- JIT is beneficial primarily for long-running, CPU bound,
+ JIT is beneficial primarily for long-running CPU bound
queries. Frequently these will be analytical queries. For short queries
the overhead of performing JIT will often be higher than
the time it can save.
@@ -117,7 +117,7 @@
If the planner, based on the above criterion, decided that
JIT is beneficial, two further decisions are
made. Firstly, if the query is more costly than the GUC expensive optimizations are
+ linkend="guc-jit-optimize-above-cost"/>, GUC expensive optimizations are
used to improve the generated code. Secondly, if the query is more costly
than the GUC, short functions
and operators used in the query will be inlined. Both of these operations
@@ -153,7 +153,7 @@
As explained in the configuration variables
- xref , , , decide whether JIT compilation is
performed for a query, and how much effort is spent doing so.
@@ -161,8 +161,8 @@
For development and debugging purposes a few additional GUCs exist. allows to inspect the generated
- bitcode. allows GDB to see
+ linkend="guc-jit-dump-bitcode"/> allows the generated bitcode to be
+ inspected. allows GDB to see
generated functions. emits
information so the perf profiler can interpret
JIT generated functions sensibly.
@@ -179,7 +179,7 @@
Extensibility
- Inlining support for extensions
+ Inlining Support for Extensions
PostgreSQL's JIT
implementation can inline the implementation of operators and functions
@@ -231,7 +231,7 @@
_PG_jit_provider_init. This function is
passed a struct that needs to be filled with the callback function
pointers for individual actions.
-
+
struct JitProviderCallbacks
{
JitProviderResetAfterErrorCB reset_after_error;
@@ -239,7 +239,7 @@ struct JitProviderCallbacks
JitProviderCompileExprCB compile_expr;
};
extern void _PG_jit_provider_init(JitProviderCallbacks *cb);
-
+
diff --git a/src/backend/jit/README b/src/backend/jit/README
index 03ec3253ee5..b37dcbe0c16 100644
--- a/src/backend/jit/README
+++ b/src/backend/jit/README
@@ -1,18 +1,18 @@
-What is Just in Time Compilation
-================================
+What is Just-in-Time Compilation?
+=================================
-Just in Time Compilation (JIT) is the process of turning some form of
+Just-in-Time compilation (JIT) is the process of turning some form of
interpreted program evaluation into a native program, and doing so at
runtime.
-E.g. instead of using a facility that can evaluate arbitrary arbitrary
+For example, instead of using a facility that can evaluate arbitrary
SQL expressions to evaluate an 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
-ahead of time (AOT). Given the way JIT compilation is used in
+ahead-of-time (AOT). Given the way JIT compilation is used in
postgres, the lines between interpretation, AOT and JIT are somewhat
blurry.
@@ -23,8 +23,8 @@ function just handling a specific type of table, despite tuple
deforming not commonly being understood as a "program".
-Why JIT
-=======
+Why JIT?
+========
Parts of postgres are commonly bottlenecked by comparatively small
pieces of CPU intensive code. In a number of cases that is because the
@@ -52,11 +52,11 @@ How to JIT
Postgres, by default, uses LLVM to perform JIT. LLVM was chosen
because it is developed by several large corporations and therefore
unlikely to be discontinued, because it has a license compatible with
-PostgreSQL, and because it's LLVM IR allow can be generated from C
+PostgreSQL, and because its LLVM IR can be generated from C
using the clang compiler.
-Shared Library separation
+Shared Library Separation
-------------------------
To avoid the main PostgreSQL binary directly depending on LLVM, which
@@ -127,7 +127,7 @@ used.
Error Handling
--------------
-There's two aspects to error handling. Firstly, generated (LLVM IR)
+There are two aspects to error handling. Firstly, generated (LLVM IR)
and emitted functions (mmap()ed segments) need to be cleaned up both
after a successful query execution and after an error. This is done by
registering each created JITContext with the current resource owner,
@@ -138,7 +138,7 @@ The second, less pretty, aspect of error handling is OOM handling
inside LLVM itself. The above resowner based mechanism takes care of
cleaning up emitted code upon ERROR, but there's also the chance that
LLVM itself runs out of memory. LLVM by default does *not* use any C++
-exceptions. It's allocations are primarily funneled through the
+exceptions. Its allocations are primarily funneled through the
standard "new" handlers, and some direct use of malloc() and
mmap(). For the former a 'new handler' exists
http://en.cppreference.com/w/cpp/memory/new/set_new_handler for the
@@ -193,14 +193,14 @@ Inlining
--------
One big advantage of JITing expressions is that it can significantly
-reduce the overhead of postgres' extensible function/operator
+reduce the overhead of postgres's extensible function/operator
mechanism, by inlining the body of called functions / operators.
It obviously is undesirable to maintain a second implementation of
commonly used functions, just for inlining purposes. Instead we take
advantage of the fact that the clang compiler can emit LLVM IR.
-The ability to do so allows to get the LLVM IR for all operators
+The ability to do so allows us to get the LLVM IR for all operators
(e.g. int8eq, float8pl etc), without maintaining two copies. These
bitcode files get installed into the server's
$pkglibdir/bitcode/postgres/
@@ -260,7 +260,7 @@ generation, and later compiling larger parts of queries.
When to JIT
===========
-Currently there's a number of GUCs that influence JITing:
+Currently there are a number of GUCs that influence JITing:
- jit_above_cost = -1, 0-DBL_MAX - all queries with a higher total cost
get JITed, *without* optimization (expensive part), corresponding to