<title>Configuration</title>

  <para>
   The configuration variable
   <xref linkend="guc-jit"/> determines whether <acronym>JIT</acronym>
   compilation is enabled or disabled.
   If it is enabled, the configuration variables
   <xref linkend="guc-jit-above-cost"/>, <xref
   linkend="guc-jit-inline-above-cost"/>, and <xref
   linkend="guc-jit-optimize-above-cost"/> determine
   whether <acronym>JIT</acronym> compilation is performed for a query,
   and how much effort is spent doing so.
  </para>

  <para>
   <xref linkend="guc-jit-provider"/> determines which <acronym>JIT</acronym>
   implementation is used. It is rarely required to be changed. See <xref
   linkend="jit-pluggable"/>.
  </para>

  <para>
   For development and debugging purposes a few additional configuration
   parameters exist, as described in
   <xref linkend="runtime-config-developer"/>.
  </para>
 </sect1>

 <sect1 id="jit-extensibility">
  <title>Extensibility</title>

  <sect2 id="jit-extensibility-bitcode">
   <title>Inlining Support for Extensions</title>
   <para>
    <productname>PostgreSQL</productname>'s <acronym>JIT</acronym>
    implementation can inline the bodies of functions
    of types <literal>C</literal> and <literal>internal</literal>, 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 <link linkend="extend-pgxs">PGXS</link> to build an extension
    against a server that has been compiled with LLVM JIT support, the
    relevant files will be built and installed automatically.
   </para>

   <para>
    The relevant files have to be installed into
    <filename>$pkglibdir/bitcode/$extension/</filename> and a summary of them
    into <filename>$pkglibdir/bitcode/$extension.index.bc</filename>, where
    <literal>$pkglibdir</literal> is the directory returned by
    <literal>pg_config --pkglibdir</literal> and <literal>$extension</literal>
    is the base name of the extension's shared library.

    <note>
     <para>
      For functions built into <productname>PostgreSQL</productname> itself,
      the bitcode is installed into
      <literal>$pkglibdir/bitcode/postgres</literal>.
     </para>
    </note>
   </para>
  </sect2>

  <sect2 id="jit-pluggable">
   <title>Pluggable <acronym>JIT</acronym> Providers</title>

   <para>
    <productname>PostgreSQL</productname> provides a <acronym>JIT</acronym>
    implementation based on <productname>LLVM</productname>.  The interface to
    the <acronym>JIT</acronym> provider is pluggable and the provider can be
    changed without recompiling (although currently, the build process only
    provides inlining support data for <productname>LLVM</productname>).
    The active provider is chosen via the setting
    <xref linkend="guc-jit-provider"/>.
   </para>

   <sect3 id="jit-pluggable-provider-interface">
    <title><acronym>JIT</acronym> Provider Interface</title>
    <para>
     A <acronym>JIT</acronym> provider is loaded by dynamically loading the
     named shared library. The normal library search path is used to locate
     the library. To provide the required <acronym>JIT</acronym> provider
     callbacks and to indicate that the library is actually a
     <acronym>JIT</acronym> provider, it needs to provide a C function named
     <function>_PG_jit_provider_init</function>. This function is passed a
     struct that needs to be filled with the callback function pointers for
     individual actions:
<programlisting>
struct JitProviderCallbacks
{
    JitProviderResetAfterErrorCB reset_after_error;
    JitProviderReleaseContextCB release_context;
    JitProviderCompileExprCB compile_expr;
};

extern void _PG_jit_provider_init(JitProviderCallbacks *cb);
</programlisting>
    </para>
   </sect3>
  </sect2>
 </sect1>

</chapter>