Movatterモバイル変換


[0]ホーム

URL:



Facebook
Postgres Pro
Facebook
Downloads
29.2. When toJIT?
Prev UpChapter 29. Just-in-Time Compilation (JIT)Home Next

29.2. When toJIT?#

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

To determine whetherJIT compilation should be used, the total estimated cost of a query (seeChapter 65 andSection 18.7.2) is used. The estimated cost of the query will be compared with the setting ofjit_above_cost. If the cost is higher,JIT compilation will be performed. Two further decisions are then needed. Firstly, if the estimated cost is more than the setting ofjit_inline_above_cost, short functions and operators used in the query will be inlined. Secondly, if the estimated cost is more than the setting ofjit_optimize_above_cost, expensive optimizations are applied to improve the generated code. Each of these options increases theJIT compilation overhead, but can reduce query execution time considerably.

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 (seePREPARE), the values of the configuration parameters in effect at prepare time control the decisions, not the settings at execution time.

EXPLAIN can be used to see whetherJIT is used or not. As an example, here is a query that is not usingJIT:

=# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;                                                 QUERY PLAN-------------------------------------------------------------------​------------------------------------------ Aggregate  (cost=16.27..16.29 rows=1 width=8) (actual time=0.303..0.303 rows=1 loops=1)   ->  Seq Scan on pg_class  (cost=0.00..15.42 rows=342 width=4) (actual time=0.017..0.111 rows=356 loops=1) Planning Time: 0.116 ms Execution Time: 0.365 ms(4 rows)

Given the cost of the plan, it is entirely reasonable that noJIT was used; the cost ofJIT would have been bigger than the potential savings. Adjusting the cost limits will lead toJIT use:

=# SET jit_above_cost = 10;SET=# EXPLAIN ANALYZE SELECT SUM(relpages) FROM pg_class;                                                 QUERY PLAN-------------------------------------------------------------------​------------------------------------------ Aggregate  (cost=16.27..16.29 rows=1 width=8) (actual time=6.049..6.049 rows=1 loops=1)   ->  Seq Scan on pg_class  (cost=0.00..15.42 rows=342 width=4) (actual time=0.019..0.052 rows=356 loops=1) Planning Time: 0.133 ms JIT:   Functions: 3   Options: Inlining false, Optimization false, Expressions true, Deforming true   Timing: Generation 1.259 ms (Deform 0.000 ms), Inlining 0.000 ms, Optimization 0.797 ms, Emission 5.048 ms, Total 7.104 ms Execution Time: 7.416 ms

As visible here,JIT was used, but inlining and expensive optimization were not. Ifjit_inline_above_cost orjit_optimize_above_cost were also lowered, that would change.


Prev Up Next
29.1. What IsJIT compilation? Home 29.3. Configuration
pdfepub
Go to Postgres Pro Standard 17
By continuing to browse this website, you agree to the use of cookies. Go toPrivacy Policy.

[8]ページ先頭

©2009-2025 Movatter.jp