significant percentage of the overhead to be optimized away.
   </para>
  </sect2>

  <sect2 id="jit-optimization">
   <title>Optimization</title>
   <para>
    <productname>LLVM</productname> has support for optimizing generated
    code. Some of the optimizations are cheap enough to be performed whenever
    <acronym>JIT</acronym> is used, while others are only beneficial for
    longer-running queries.
    See <ulink url="https://llvm.org/docs/Passes.html#transform-passes"/> for
    more details about optimizations.
   </para>
  </sect2>

 </sect1>

 <sect1 id="jit-decision">
  <title>When to <acronym>JIT</acronym>?</title>

  <para>
   <acronym>JIT</acronym> compilation is beneficial primarily for long-running
   CPU-bound queries. Frequently these will be analytical queries.  For short
   queries the added overhead of performing <acronym>JIT</acronym> compilation
   will often be higher than the time it can save.
  </para>

  <para>
   To determine whether <acronym>JIT</acronym> compilation should be used,
   the total estimated cost of a query (see
   <xref linkend="planner-stats-details"/> and
   <xref linkend="runtime-config-query-constants"/>) is used.
   The estimated cost of the query will be compared with the setting of <xref
   linkend="guc-jit-above-cost"/>. If the cost is higher,
   <acronym>JIT</acronym> compilation will be performed.
   Two further decisions are then needed.
   Firstly, if the estimated cost is more
   than the setting of <xref linkend="guc-jit-inline-above-cost"/>, short
   functions and operators used in the query will be inlined.
   Secondly, if the estimated cost is more than the setting of <xref
   linkend="guc-jit-optimize-above-cost"/>, expensive optimizations are
   applied to improve the generated code.
   Each of these options increases the <acronym>JIT</acronym> compilation
   overhead, but can reduce query execution time considerably.
  </para>

  <para>
   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 <xref linkend="sql-prepare"/>), the values of the
   configuration parameters in effect at prepare time control the decisions,
   not the settings at execution time.
  </para>

  <note>
   <para>
    If <xref linkend="guc-jit"/> is set to <literal>off</literal>, or if no
    <acronym>JIT</acronym> implementation is available (for example because
    the server was compiled without <literal>--with-llvm</literal>),
    <acronym>JIT</acronym> will not be performed, even if it would be
    beneficial based on the above criteria.  Setting <xref linkend="guc-jit"/>
    to <literal>off</literal> has effects at both plan and execution time.
   </para>
  </note>

  <para>
   <xref linkend="sql-explain"/> can be used to see whether
   <acronym>JIT</acronym> is used or not.  As an example, here is a query that
   is not using <acronym>JIT</acronym>:
<screen>
=# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;
                                                 QUERY PLAN
-------------------------------------------------------------------&zwsp;------------------------------------------
 Aggregate  (cost=16.27..16.29 rows=1 width=8) (actual time=0.303..0.303 rows=1.00 loops=1)
   Buffers: shared hit=14
   ->  Seq Scan on pg_class  (cost=0.00..15.42 rows=342 width=4) (actual time=0.017..0.111 rows=356.00 loops=1)
         Buffers: shared hit=14
 Planning Time: 0.116 ms
 Execution Time: 0.365 ms
</screen>
   Given the cost of the plan, it is entirely reasonable that no
   <acronym>JIT</acronym> was used; the cost of <acronym>JIT</acronym> would
   have been bigger than the potential savings. Adjusting the cost limits
   will lead to <acronym>JIT</acronym> use:
<screen>
=# SET jit_above_cost = 10;
SET
=# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;
                                                 QUERY PLAN
-------------------------------------------------------------------&zwsp;------------------------------------------