begriffs open source - ai-pg/blob - full-docs/txt/jit-decision.txt

   1
   2 30.2. When to JIT? #
   3
   4    JIT compilation is beneficial primarily for long-running CPU-bound
   5    queries. Frequently these will be analytical queries. For short queries
   6    the added overhead of performing JIT compilation will often be higher
   7    than the time it can save.
   8
   9    To determine whether JIT compilation should be used, the total
  10    estimated cost of a query (see Chapter 69 and Section 19.7.2) is used.
  11    The estimated cost of the query will be compared with the setting of
  12    jit_above_cost. If the cost is higher, JIT compilation will be
  13    performed. Two further decisions are then needed. Firstly, if the
  14    estimated cost is more than the setting of jit_inline_above_cost, short
  15    functions and operators used in the query will be inlined. Secondly, if
  16    the estimated cost is more than the setting of jit_optimize_above_cost,
  17    expensive optimizations are applied to improve the generated code. Each
  18    of these options increases the JIT compilation overhead, but can reduce
  19    query execution time considerably.
  20
  21    These cost-based decisions will be made at plan time, not execution
  22    time. This means that when prepared statements are in use, and a
  23    generic plan is used (see PREPARE), the values of the configuration
  24    parameters in effect at prepare time control the decisions, not the
  25    settings at execution time.
  26
  27 Note
  28
  29    If jit is set to off, or if no JIT implementation is available (for
  30    example because the server was compiled without --with-llvm), JIT will
  31    not be performed, even if it would be beneficial based on the above
  32    criteria. Setting jit to off has effects at both plan and execution
  33    time.
  34
  35    EXPLAIN can be used to see whether JIT is used or not. As an example,
  36    here is a query that is not using JIT:
  37 =# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;
  38                                                  QUERY PLAN
  39 -------------------------------------------------------------------------------
  40 ------------------------------
  41  Aggregate  (cost=16.27..16.29 rows=1 width=8) (actual time=0.303..0.303 rows=1.
  42 00 loops=1)
  43    Buffers: shared hit=14
  44    ->  Seq Scan on pg_class  (cost=0.00..15.42 rows=342 width=4) (actual time=0.
  45 017..0.111 rows=356.00 loops=1)
  46          Buffers: shared hit=14
  47  Planning Time: 0.116 ms
  48  Execution Time: 0.365 ms
  49
  50    Given the cost of the plan, it is entirely reasonable that no JIT was
  51    used; the cost of JIT would have been bigger than the potential
  52    savings. Adjusting the cost limits will lead to JIT use:
  53 =# SET jit_above_cost = 10;
  54 SET
  55 =# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;
  56                                                  QUERY PLAN
  57 -------------------------------------------------------------------------------
  58 ------------------------------
  59  Aggregate  (cost=16.27..16.29 rows=1 width=8) (actual time=6.049..6.049 rows=1.
  60 00 loops=1)
  61    Buffers: shared hit=14
  62    ->  Seq Scan on pg_class  (cost=0.00..15.42 rows=342 width=4) (actual time=0.
  63 019..0.052 rows=356.00 loops=1)
  64          Buffers: shared hit=14
  65  Planning Time: 0.133 ms
  66  JIT:
  67    Functions: 3
  68    Options: Inlining false, Optimization false, Expressions true, Deforming true
  69    Timing: Generation 1.259 ms (Deform 0.000 ms), Inlining 0.000 ms, Optimizatio
  70 n 0.797 ms, Emission 5.048 ms, Total 7.104 ms
  71  Execution Time: 7.416 ms
  72
  73    As visible here, JIT was used, but inlining and expensive optimization
  74    were not. If jit_inline_above_cost or jit_optimize_above_cost were also
  75    lowered, that would change.