-
jit_above_cost (floating point)
- Sets the planner's cutoff above which JIT compilation is used as part
- of query execution (see ). Performing
-
JIT costs time but can accelerate query execution.
-
+ Sets the query cost above which JIT compilation is activated, if
+ enabled (see ).
+ Performing
JIT costs planning time but can
+ accelerate query execution.
+ Setting this to -1 disables JIT compilation.
The default is 100000.
- optimize-above-cost" xreflabel="jit_optimize_above_cost">
- jit_optimize_above_cost (floating point)
+ inline-above-cost" xreflabel="jit_inline_above_cost">
+ jit_inline_above_cost (floating point)
-
jit_optimize_above_cost configuration parameter+
jit_inline_above_cost configuration parameter
- Sets the planner's cutoff above which JIT compiled programs (see
- linkend="guc-jit-above-cost"/>) are optimized. Optimization initially
- takes time, but can improve execution speed. It is not meaningful to
- set this to a lower value than >.
-
+ Sets the query cost above which JIT compilation attempts to inline
+ functions and operators. Inlining adds planning time, but can
+ improve execution speed. It is not meaningful to set this to less
+ than jit_above_cost>.
+ Setting this to -1 disables inlining.
The default is 500000.
- inline-above-cost" xreflabel="jit_inline_above_cost">
- jit_inline_above_cost (floating point)
+ optimize-above-cost" xreflabel="jit_optimize_above_cost">
+ jit_optimize_above_cost (floating point)
-
jit_inline_above_cost configuration parameter+
jit_optimize_above_cost configuration parameter
- Sets the planner's cutoff above which JIT compiled programs (see
- linkend="guc-jit-above-cost"/>) attempt to inline functions and
- operators. Inlining initially takes time, but can improve execution
- speed. It is unlikely to be beneficial to set
- jit_inline_above_cost below
- jit_optimize_above_cost.
-
+ Sets the query cost above which JIT compilation applies expensive
+ optimizations. Such optimization adds planning time, but can improve
+ execution speed. It is not meaningful to set this to less
+ than jit_above_cost, and it is unlikely to be
+ beneficial to set it to more
+ than jit_inline_above_cost.
+ Setting this to -1 disables expensive optimizations.
The default is 500000.
- Determines whether
JIT may be used by
+ Determines whether
JIT compilation may be used by
PostgreSQL, if available (see
linkend="jit"/>).
-
The default is on.
- Determines which JIT provider (see ) is
- used. The built-in default is llvmjit.
+ This variable is the name of the JIT provider library to be used
+ (see ).
+ The default is llvmjit.
+ This parameter can only be set at server start.
+
- If set to a non-existent library
JIT will not be
+ If set to a non-existent library
, JIT will not be
available, but no error will be raised. This allows JIT support to be
installed separately from the main
-
- This parameter can only be set at server start.
If LLVM has the required functionality, register generated functions
with
GDB. This makes debugging easier.
-
- The default setting is off, and can only be set at
- server start.
+ The default setting is off.
+ This parameter can only be set at server start.
Writes the generated
LLVM IR out to the
file system, inside . This is only
useful for working on the internals of the JIT implementation.
-
- The default setting is off, and it can only be
- changed by a superuser.
+ The default setting is off.
+ This parameter can only be changed by a superuser.
- Determines whether expressions are JIT compiled, subject to costing
- decisions (see ). The default is
+ Determines whether expressions are JIT compiled, when JIT compilation
+ is activated (see ). The default is
on.
- If LLVM has the required functionality, emit required data to allow
+ If LLVM has the required functionality, emit the data needed to allow
perf to profile functions generated by JIT.
This writes out files to $HOME/.debug/jit/; the
user is responsible for performing cleanup when desired.
-
- The default setting is off, and can only be set at
- server start.
+ The default setting is off.
+ This parameter can only be set at server start.
- Determines whether tuple deforming is JIT compiled, subject to costing
- decisions (see ). The default is
- on.
+ Determines whether tuple deforming is JIT compiled, when JIT
+ compilation is activated (see ).
+ The default is on.
What is <acronym>JIT</acronym> compilation?
- Just-in-
time compilation (JIT) is the process of turning
+ Just-in-
Time (JIT) compilation is the process of turning
some form of interpreted program evaluation into a native program, and
doing so at run time.
-
- 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.
+ For example, instead of using general-purpose code that can evaluate
+ arbitrary SQL expressions to evaluate a particular SQL predicate
+ like WHERE a.col = 3, it is possible to generate a
+ function that is specific to that expression and can be natively executed
+ by the CPU, yielding a speedup.
PostgreSQL has builtin support to perform
JIT compilation using
url="https://llvm.org/">
LLVM when
-
PostgreSQL was built with
- teral>--with-llvm (see ).
+
PostgreSQL is built with
+ nk linkend="configure-with-llvm">--with-llvm.
-
-
Optimization
-
LLVM has support for optimizing generated
- code. Some of the optimizations are cheap enough to be performed whenever
-
JIT is used, while others are only beneficial for
- longer running queries.
-
- more details about optimizations.
-
-
-
Inlining
PostgreSQL is very extensible and allows new
data types, functions, operators and other database objects to be defined;
- see . In fact the built-in ones are implemented
+ see . In fact the built-in objects are implemented
using nearly the same mechanisms. This extensibility implies some
overhead, for example 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 a
+ To reduce that overhead
, JIT compilation can inline the
+ bodies of small functions into the expressions using them. That allows a
significant percentage of the overhead to be optimized away.
+
+
Optimization
+
LLVM has support for optimizing generated
+ code. Some of the optimizations are cheap enough to be performed whenever
+
JIT is used, while others are only beneficial for
+ longer-running queries.
+ more details about optimizations.
+
+
+
JIT compilation is beneficial primarily for long-running
- CPU bound queries. Frequently these will be analytical queries. For short
+ CPU-bound queries. Frequently these will be analytical queries. For short
queries the added overhead of performing
JIT compilation
will often be higher than the time it can save.
- To determine whether
JIT compilation is used, the total
- cost of a query (see
and
- linkend="runtime-config-query-constants"/>) is used.
-
-
- The cost of the query will be compared with the setting of
+ To determine whether
JIT compilation should be used,
+ the total estimated cost of a query (see
+ and
+ ) is used.
+ The estimated cost of the query will be compared with the setting of
linkend="guc-jit-above-cost"/>. If the cost is higher,
JIT compilation will be performed.
-
-
- If the planner, based on the above criterion, decided that
-
JIT compilation is beneficial, two further decisions are
- made. Firstly, if the query is more costly than the setting of
+ Two further decisions are then needed.
+ Firstly, if the estimated cost is more
+ than the setting of , short
+ functions and operators used in the query will be inlined.
+ Secondly, if the estimated cost is more than the setting of
linkend="guc-jit-optimize-above-cost"/>, expensive optimizations are
- used to improve the generated code. Secondly, if the query is more costly
- than the setting of , short functions
- and operators used in the query will be inlined. Both of these operations
- increase the
JIT overhead, but can reduce query
- execution time considerably.
+ applied to improve the generated code.
+ Each of these options increases the
JIT compilation
+ overhead, but can reduce query execution time considerably.
- This cost based decision will be made at plan time, not execution
- time. This means that when prepared statements are in use, and the generic
- plan is used (see ), the values of the
- configuration parameters set at prepare time take effect, not the settings at execution time.
+ These cost-based decisions will be made at plan time, not execution
+ time. This means that when prepared statements are in use, and a generic
+ plan is used (see ), the values of the
+ configuration parameters in effect at prepare time control the decisions,
+ not the settings at execution time.
- If is set to off, or no
+ If is set to off, or if no
JIT implementation is available (for example because
the server was compiled without --with-llvm),
-
JIT will not be performed, even if
considered to be
+
JIT will not be performed, even if
it would be
beneficial based on the above criteria. Setting
- to off takes effect both at plan and at execution time.
+ to off has effects at both plan and execution time.
(4 rows)
Given the cost of the plan, it is entirely reasonable that no
-
JIT was used
, the cost of
JIT would
- have been bigger than the savings. Adjusting the cost limits will lead to
+
JIT was used
; the cost of
JIT would
+ have been bigger than the potential savings. Adjusting the cost limits
=# SET jit_above_cost = 10;
SET
As visible here,
JIT was used, but inlining and
expensive optimization were not. If
- linkend="guc-jit-
optimize-above-cost"/>,
- linkend="guc-jit-inline-above-cost"/> were lowered, just like
- linkend="guc-jit-above-cost"/>, that would change.
+ linkend="guc-jit-
inline-above-cost"/> or
+ linkend="guc-jit-optimize-above-cost"/> were also lowered,
+ that would change.
Configuration
+ The configuration variable
compilation is enabled or disabled.
-
-
- As explained in the configuration variables
+ If it is enabled, the configuration variables
,
- linkend="guc-jit-
optimize-above-cost"/>,
- linkend="guc-jit-
inline-above-cost"/> decide whether JIT- compilation is performed for a query, and how much effort is spent doing
- so.
+ linkend="guc-jit-
inline-above-cost"/>, and
+ linkend="guc-jit-optimize-above-cost"/> determine
+ whether
JIT compilation is performed for a query,
+ and how much effort is spent doing so.
- For development and debugging purposes a few additional configuration parameters exist.
- 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.
+ implementation is used. It is rarely required to be changed. See
+ linkend="jit-pluggable"/>.
- implementation is used. It rarely is required to be changed. See
- linkend="jit-pluggable"/>.
+ For development and debugging purposes a few additional configuration
+ parameters exist, as described in
+ "/>.
- xreflabel="JIT Extensibility">
+
Extensibility
Inlining Support for Extensions
- implementation can inline the implementation of operators and functions
- (of type
C and
internal). See
- linkend="jit-inlining"/>. To do so for functions in extensions, the
- definition of these functions needs to be made available. When using
- linkend="extend-pgxs">PGXS to build an extension against a server
- that has been compiled with LLVM support, the relevant files will be
- installed automatically.
+ implementation can inline the bodies of functions
+ of types C and internal, as well as
+ operators based on such functions. To do so for functions in extensions,
+ the definitions of those functions need to be made available.
+ When using PGXS to build an extension
+ against a server that has been compiled with LLVM JIT support, the
+ relevant files will be built and installed automatically.
The relevant files have to be installed into
$pkglibdir/bitcode/$extension/ and a summary of them
- to $pkglibdir/bitcode/$extension.index.bc, where
+ into $pkglibdir/bitcode/$extension.index.bc, where
$pkglibdir is the directory returned by
pg_config --pkglibdir and $extension
- the base name of the extension's shared library.
+ is the base name of the extension's shared library.
-
Pluggable <acronym>JIT</acronym> Provider
+
Pluggable <acronym>JIT</acronym> Provider<span class="marked">s</span>
PostgreSQL provides a
JIT
implementation based on
LLVM. The interface to
the
JIT provider is pluggable and the provider can be
- changed without recompiling. The provider is chosen via the setting
- linkend="guc-jit-provider"/>.
+ changed without recompiling (although currently, the build process only
+ provides inlining support data for
LLVM).
+ The active provider is chosen via the setting
+ .
named shared library. The normal library search path is used to locate
the library. To provide the required
JIT provider
callbacks and to indicate that the library is actually a
-
JIT provider
it needs to provide a function named
+
JIT provider
, it needs to provide a C function named
_PG_jit_provider_init. This function is passed a
struct that needs to be filled with the callback function pointers for
- individual actions.
+ individual actions:
struct JitProviderCallbacks
{
JitProviderReleaseContextCB release_context;
JitProviderCompileExprCB compile_expr;
};
+
extern void _PG_jit_provider_init(JitProviderCallbacks *cb);
- JIT compilation of some SQL code, including support for fast evaluation
- of expressions
+ Optional Just-in-Time (JIT) compilation of some SQL code, including
+ support for fast evaluation of expressions
-->
- Add Just-In-Time
+ Add Just-in-Time
(
JIT) compilation of some parts of query plans
to improve execution speed (Andres Freund)
+
+ This feature requires
LLVM to be
+ available, and it is not currently enabled by default, even in
+ builds that support it.
+
/* GUCs */
bool jit_enabled = true;
-char *jit_provider = "llvmjit";
+char *jit_provider = NULL;
bool jit_debugging_support = false;
bool jit_dump_bitcode = false;
bool jit_expressions = true;
},
{
- {"jit_provider", PGC_POSTMASTER, FILE_LOCATIONS,
+ {"jit_provider", PGC_POSTMASTER, CLIENT_CONN_PRELOAD,
gettext_noop("JIT provider to use."),
NULL,
GUC_SUPERUSER_ONLY
#parallel_setup_cost = 1000.0 # same scale as above
#jit_above_cost = 100000 # perform JIT compilation if available
- # and query more expensive, -1 disables
-#jit_optimize_above_cost = 500000 # optimize JITed functions if query is
- # more expensive, -1 disables
-#jit_inline_above_cost = 500000 # attempt to inline operators and
- # functions if query is more expensive,
+ # and query more expensive than this;
+ # -1 disables
+#jit_inline_above_cost = 500000 # inline small functions if query is
+ # more expensive than this; -1 disables
+#jit_optimize_above_cost = 500000 # use expensive JIT optimizations if
+ # query is more expensive than this;
# -1 disables
#min_parallel_table_scan_size = 8MB
#join_collapse_limit = 8 # 1 disables collapsing of explicit
# JOIN clauses
#force_parallel_mode = off
+#jit = on # allow JIT compilation
#plan_cache_mode = auto # auto, force_generic_plan or
# force_custom_plan
#shared_preload_libraries = '' # (change requires restart)
#local_preload_libraries = ''
#session_preload_libraries = ''
+#jit_provider = 'llvmjit' # JIT library to use
# - Other Defaults -
#dynamic_library_path = '$libdir'
-#jit = on # allow JIT compilation
-#jit_provider = 'llvmjit' # JIT implementation to use
#------------------------------------------------------------------------------
# LOCK MANAGEMENT
projects / postgresql.git / commitdiff