プロホスト > ブログ > 行政 > PostgreSQL の䞊列ク゚リ

PostgreSQL の䞊列ク゚リ

PostgreSQL の䞊列ク゚リ
最近の CPU には倚くのコアが搭茉されおいたす。 長幎にわたり、アプリケヌションはデヌタベヌスにク゚リを䞊行しお送信しおきたした。 テヌブル内の耇数行に察するレポヌト ク゚リの堎合、耇数の CPU を䜿甚するずより高速に実行されたす。PostgreSQL はバヌゞョン 9.6 以降、これを実行できるようになりたした。

䞊列ク゚リ機胜を実装するには 3 幎かかりたした。ク゚リ実行のさたざたな段階でコヌドを曞き盎す必芁がありたした。 PostgreSQL 9.6 では、コヌドをさらに改善するためのむンフラストラクチャが導入されたした。 埌続のバヌゞョンでは、他のタむプのク゚リが䞊行しお実行されたす。

制限

  • すべおのコアがすでにビゞヌ状態の堎合は、䞊列実行を有効にしないでください。有効にしないず、他のリク゚ストの速床が䜎䞋したす。
  • 最も重芁なこずは、高い WORK_MEM 倀での䞊列凊理は倧量のメモリを䜿甚するこずです。各ハッシュ結合たたは゜ヌトは work_mem メモリを消費したす。
  • 䜎遅延の OLTP ク゚リは、䞊列実行によっお高速化できたせん。 たた、ク゚リが XNUMX 行を返す堎合、䞊列凊理では速床が䜎䞋するだけです。
  • 開発者は TPC-H ベンチマヌクを奜んで䜿甚したす。 もしかしたら、完党な䞊列実行を求める同様のク゚リがあるかもしれたせん。
  • 述語ロックのない SELECT ク゚リのみが䞊列実行されたす。
  • 堎合によっおは、適切なむンデックス䜜成が、䞊列モヌドでの順次テヌブル スキャンよりも優れおいるこずがありたす。
  • ク゚リずカヌ゜ルの䞀時停止はサポヌトされおいたせん。
  • りィンドり関数ず順序集合集合関数は䞊列ではありたせん。
  • I/O ワヌクロヌドでは䜕も埗られたせん。
  • 䞊列䞊べ替えアルゎリズムはありたせん。 ただし、゜ヌトを䜿甚したク゚リは、いく぀かの点で䞊行しお実行できたす。
  • CTE (WITH ...) をネストされた SELECT に眮き換えお、䞊列凊理を有効にしたす。
  • サヌドパヌティのデヌタ ラッパヌはただ䞊列凊理をサポヌトしおいたせん (ただし、䞊列凊理は可胜です)。
  • FULL OUTER JOIN はサポヌトされおいたせん。
  • max_rows は䞊列凊理を無効にしたす。
  • ク゚リに PARALLEL SAFE ずマヌクされおいない関数がある堎合、その関数はシングルスレッドになりたす。
  • SERIALIZABLE トランザクション分離レベルでは、䞊列凊理が無効になりたす。

テスト環境

PostgreSQL 開発者は、TPC-H ベンチマヌク ク゚リの応答時間を短瞮しようずしたした。 ベンチマヌクをダりンロヌドしお、 PostgreSQLに適応させる。 これは TPC-H ベンチマヌクの非公匏な䜿甚であり、デヌタベヌスやハヌドりェアの比范を目的ずしたものではありたせん。

  1. TPC-H_Tools_v2.17.3.zip (たたはそれ以降のバヌゞョン) をダりンロヌドしたす。 TPC オフサむトから.
  2. makefile.suite の名前を Makefile に倉曎し、ここで説明されおいるように倉曎したす。 https://github.com/tvondra/pg_tpch 。 make コマンドを䜿甚しおコヌドをコンパむルしたす。
  3. デヌタを生成したす。 ./dbgen -s 10 23 GB のデヌタベヌスを䜜成したす。 これは、䞊列ク゚リず非䞊列ク゚リのパフォヌマンスの違いを確認するには十分です。
  4. ファむルを倉換する tbl в csv с for О sed.
  5. リポゞトリのクロヌンを䜜成する pg_tpch ファむルをコピヌしたす csv в pg_tpch/dss/data.
  6. コマンドでク゚リを䜜成する qgen.
  7. コマンドを䜿甚しおデヌタベヌスにデヌタをロヌドしたす ./tpch.sh.

䞊列順次スキャン

䞊列読み取りのせいではなく、デヌタが倚くの CPU コアに分散されおいるため、高速になる可胜性がありたす。 最新のオペレヌティング システムでは、PostgreSQL デヌタ ファむルは適切にキャッシュされたす。 先読みを䜿甚するず、PG デヌモンが芁求するよりも倧きなブロックをストレヌゞから取埗できたす。 したがっお、ク゚リのパフォヌマンスはディスク I/O によっお制限されたせん。 次の目的で CPU サむクルを消費したす。

  • テヌブルペヌゞから䞀床に XNUMX 行ず぀読み取りたす。
  • 文字列の倀ず条件を比范する WHERE.

簡単なク゚リを実行しおみたしょう select:

tpch=# explain analyze select l_quantity as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Seq Scan on lineitem (cost=0.00..1964772.00 rows=58856235 width=5) (actual time=0.014..16951.669 rows=58839715 loops=1)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 1146337
Planning Time: 0.203 ms
Execution Time: 19035.100 ms

シヌケンシャル スキャンでは、集蚈なしで生成される行が倚すぎるため、ク゚リは単䞀の CPU コアによっお実行されたす。

远加するず SUM(), XNUMX ぀のワヌクフロヌがク゚リの高速化に圹立぀こずがわかりたす。

explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1589702.14..1589702.15 rows=1 width=32) (actual time=8553.365..8553.365 rows=1 loops=1)
-> Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)
-> Parallel Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 382112
Planning Time: 0.241 ms
Execution Time: 8555.131 ms

䞊列集蚈

Parallel Seq Scan ノヌドは、郚分集蚈甚の行を生成したす。 「郚分集玄」ノヌドは、次を䜿甚しおこれらの行をトリミングしたす。 SUM()。 最埌に、各ワヌカヌ プロセスからの SUM カりンタヌが「Gather」ノヌドによっお収集されたす。

最終結果は、「Finalize Aggregate」ノヌドによっお蚈算されたす。 独自の集蚈関数がある堎合は、それらを「䞊列安党」ずしおマヌクするこずを忘れないでください。

ワヌカヌプロセスの数

ワヌカヌ プロセスの数は、サヌバヌを再起動せずに増やすこずができたす。

explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1589702.14..1589702.15 rows=1 width=32) (actual time=8553.365..8553.365 rows=1 loops=1)
-> Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)
-> Parallel Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 382112
Planning Time: 0.241 ms
Execution Time: 8555.131 ms

䜕が起きおる 䜜業プロセスは 2 倍になりたしたが、リク゚ストの速床は 1,6599 倍にすぎたせんでした。 蚈算は面癜いですね。 2 ぀のワヌカヌ プロセスず 1 ぀のリヌダヌがありたした。 倉曎埌は4+1になりたした。

䞊列凊理による最倧速床向䞊: 5/3 = 1,66(6) 倍。

それはどのように動䜜したすか

ПрПцессы

リク゚ストの実行は垞に先頭のプロセスから開始されたす。 リヌダヌはすべおの非䞊列凊理ず䞀郚の䞊列凊理を実行したす。 同じリク゚ストを実行する他のプロセスはワヌカヌ プロセスず呌ばれたす。 むンフラストラクチャを䜿甚した䞊列凊理 動的バックグラりンドワヌカヌプロセス (バヌゞョン 9.4 以降)。 PostgreSQL の他の郚分はスレッドではなくプロセスを䜿甚するため、3 ぀のワヌカヌ プロセスを含むク゚リは埓来の凊理より 4 倍高速になる可胜性がありたす。

盞互䜜甚

ワヌカヌ プロセスは、メッセヌゞ キュヌ (共有メモリに基づく) を通じおリヌダヌず通信したす。 各プロセスには、゚ラヌ甚ずタプル甚の 2 ぀のキュヌがありたす。

ワヌクフロヌはいく぀必芁ですか?

最小制限はパラメヌタで指定されたす max_parallel_workers_per_gather。 次に、リク゚スト ランナヌは、パラメヌタヌによっお制限されたプヌルからワヌカヌ プロセスを取埗したす。 max_parallel_workers size。 最埌の制限は、 max_worker_processes、぀たりバックグラりンドプロセスの総数です。

ワヌカヌプロセスを割り圓おられなかった堎合は、シングルプロセスでの凊理ずなりたす。

ク゚リ プランナヌは、テヌブルたたはむンデックスのサむズに応じおワヌクフロヌを削枛できたす。 これにはパラメヌタがありたす min_parallel_table_scan_size О min_parallel_index_scan_size.

set min_parallel_table_scan_size='8MB'
8MB table => 1 worker
24MB table => 2 workers
72MB table => 3 workers
x => log(x / min_parallel_table_scan_size) / log(3) + 1 worker

テヌブルが 3 倍になるたびに、 min_parallel_(index|table)_scan_size, Postgresはワヌカヌプロセスを远加したす。 ワヌクフロヌの数はコストに基づいおいたせん。 埪環䟝存関係により、耇雑な実装が困難になりたす。 代わりに、プランナヌは単玔なルヌルを䜿甚したす。

実際には、これらのルヌルが垞に運甚環境に適しおいるわけではないため、特定のテヌブルのワヌカヌ プロセスの数を倉曎できたす: ALTER TABLE ... SET (parallel_workers = N).

なぜ䞊列凊理が䜿われないのでしょうか?

制限の長いリストに加えお、コストのチェックもありたす。

parallel_setup_cost - 短いリク゚ストの䞊列凊理を避けるため。 このパラメヌタは、メモリの準備、プロセスの開始、および最初のデヌタ亀換にかかる時間を掚定したす。

parallel_tuple_cost: リヌダヌずワヌカヌ間の通信は、䜜業プロセスからのタプルの数に比䟋しお遅延する可胜性がありたす。 このパラメヌタはデヌタ亀換のコストを蚈算したす。

ネストされたルヌプ結合

PostgreSQL 9.6+ ЌПжет выпПлМять влПжеММые цОклы параллельМП — этП прПстая ПперацОя.

explain (costs off) select c_custkey, count(o_orderkey)
                from    customer left outer join orders on
                                c_custkey = o_custkey and o_comment not like '%special%deposits%'
                group by c_custkey;
                                      QUERY PLAN
--------------------------------------------------------------------------------------
 Finalize GroupAggregate
   Group Key: customer.c_custkey
   ->  Gather Merge
         Workers Planned: 4
         ->  Partial GroupAggregate
               Group Key: customer.c_custkey
               ->  Nested Loop Left Join
                     ->  Parallel Index Only Scan using customer_pkey on customer
                     ->  Index Scan using idx_orders_custkey on orders
                           Index Cond: (customer.c_custkey = o_custkey)
                           Filter: ((o_comment)::text !~~ '%special%deposits%'::text)

コレクションは最埌の段階で発生するため、ネストされたルヌプ巊結合は䞊列操䜜です。 䞊列むンデックスのみのスキャンはバヌゞョン 10 でのみ導入されたした。䞊列シリアル スキャンず同様に機胜したす。 状態 c_custkey = o_custkey クラむアント文字列ごずに XNUMX ぀の泚文を読み取りたす。 したがっお、平行ではありたせん。

ハッシュ結合

PostgreSQL 11 たでは、各ワヌカヌ プロセスが独自のハッシュ テヌブルを䜜成したす。たた、これらのプロセスが XNUMX ぀以䞊ある堎合、パフォヌマンスは向䞊したせん。 新バヌゞョンではハッシュテヌブルが共有されるようになりたした。 各ワヌカヌ プロセスは WORK_MEM を䜿甚しおハッシュ テヌブルを䜜成できたす。

select
        l_shipmode,
        sum(case
                when o_orderpriority = '1-URGENT'
                        or o_orderpriority = '2-HIGH'
                        then 1
                else 0
        end) as high_line_count,
        sum(case
                when o_orderpriority <> '1-URGENT'
                        and o_orderpriority <> '2-HIGH'
                        then 1
                else 0
        end) as low_line_count
from
        orders,
        lineitem
where
        o_orderkey = l_orderkey
        and l_shipmode in ('MAIL', 'AIR')
        and l_commitdate < l_receiptdate
        and l_shipdate < l_commitdate
        and l_receiptdate >= date '1996-01-01'
        and l_receiptdate < date '1996-01-01' + interval '1' year
group by
        l_shipmode
order by
        l_shipmode
LIMIT 1;
                                                                                                                                    QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=1964755.66..1964961.44 rows=1 width=27) (actual time=7579.592..7922.997 rows=1 loops=1)
   ->  Finalize GroupAggregate  (cost=1964755.66..1966196.11 rows=7 width=27) (actual time=7579.590..7579.591 rows=1 loops=1)
         Group Key: lineitem.l_shipmode
         ->  Gather Merge  (cost=1964755.66..1966195.83 rows=28 width=27) (actual time=7559.593..7922.319 rows=6 loops=1)
               Workers Planned: 4
               Workers Launched: 4
               ->  Partial GroupAggregate  (cost=1963755.61..1965192.44 rows=7 width=27) (actual time=7548.103..7564.592 rows=2 loops=5)
                     Group Key: lineitem.l_shipmode
                     ->  Sort  (cost=1963755.61..1963935.20 rows=71838 width=27) (actual time=7530.280..7539.688 rows=62519 loops=5)
                           Sort Key: lineitem.l_shipmode
                           Sort Method: external merge  Disk: 2304kB
                           Worker 0:  Sort Method: external merge  Disk: 2064kB
                           Worker 1:  Sort Method: external merge  Disk: 2384kB
                           Worker 2:  Sort Method: external merge  Disk: 2264kB
                           Worker 3:  Sort Method: external merge  Disk: 2336kB
                           ->  Parallel Hash Join  (cost=382571.01..1957960.99 rows=71838 width=27) (actual time=7036.917..7499.692 rows=62519 loops=5)
                                 Hash Cond: (lineitem.l_orderkey = orders.o_orderkey)
                                 ->  Parallel Seq Scan on lineitem  (cost=0.00..1552386.40 rows=71838 width=19) (actual time=0.583..4901.063 rows=62519 loops=5)
                                       Filter: ((l_shipmode = ANY ('{MAIL,AIR}'::bpchar[])) AND (l_commitdate < l_receiptdate) AND (l_shipdate < l_commitdate) AND (l_receiptdate >= '1996-01-01'::date) AND (l_receiptdate < '1997-01-01 00:00:00'::timestamp without time zone))
                                       Rows Removed by Filter: 11934691
                                 ->  Parallel Hash  (cost=313722.45..313722.45 rows=3750045 width=20) (actual time=2011.518..2011.518 rows=3000000 loops=5)
                                       Buckets: 65536  Batches: 256  Memory Usage: 3840kB
                                       ->  Parallel Seq Scan on orders  (cost=0.00..313722.45 rows=3750045 width=20) (actual time=0.029..995.948 rows=3000000 loops=5)
 Planning Time: 0.977 ms
 Execution Time: 7923.770 ms

TPC-H のク゚リ 12 は、䞊列ハッシュ接続を明確に瀺しおいたす。 各ワヌカヌ プロセスは、共通のハッシュ テヌブルの䜜成に貢献したす。

マヌゞ結合

マヌゞ結合は本質的に非䞊列です。 これがク゚リの最埌のステップであっおも心配する必芁はありたせん。それでも䞊行しお実行できたす。

-- Query 2 from TPC-H
explain (costs off) select s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment
from    part, supplier, partsupp, nation, region
where
        p_partkey = ps_partkey
        and s_suppkey = ps_suppkey
        and p_size = 36
        and p_type like '%BRASS'
        and s_nationkey = n_nationkey
        and n_regionkey = r_regionkey
        and r_name = 'AMERICA'
        and ps_supplycost = (
                select
                        min(ps_supplycost)
                from    partsupp, supplier, nation, region
                where
                        p_partkey = ps_partkey
                        and s_suppkey = ps_suppkey
                        and s_nationkey = n_nationkey
                        and n_regionkey = r_regionkey
                        and r_name = 'AMERICA'
        )
order by s_acctbal desc, n_name, s_name, p_partkey
LIMIT 100;
                                                QUERY PLAN
----------------------------------------------------------------------------------------------------------
 Limit
   ->  Sort
         Sort Key: supplier.s_acctbal DESC, nation.n_name, supplier.s_name, part.p_partkey
         ->  Merge Join
               Merge Cond: (part.p_partkey = partsupp.ps_partkey)
               Join Filter: (partsupp.ps_supplycost = (SubPlan 1))
               ->  Gather Merge
                     Workers Planned: 4
                     ->  Parallel Index Scan using <strong>part_pkey</strong> on part
                           Filter: (((p_type)::text ~~ '%BRASS'::text) AND (p_size = 36))
               ->  Materialize
                     ->  Sort
                           Sort Key: partsupp.ps_partkey
                           ->  Nested Loop
                                 ->  Nested Loop
                                       Join Filter: (nation.n_regionkey = region.r_regionkey)
                                       ->  Seq Scan on region
                                             Filter: (r_name = 'AMERICA'::bpchar)
                                       ->  Hash Join
                                             Hash Cond: (supplier.s_nationkey = nation.n_nationkey)
                                             ->  Seq Scan on supplier
                                             ->  Hash
                                                   ->  Seq Scan on nation
                                 ->  Index Scan using idx_partsupp_suppkey on partsupp
                                       Index Cond: (ps_suppkey = supplier.s_suppkey)
               SubPlan 1
                 ->  Aggregate
                       ->  Nested Loop
                             Join Filter: (nation_1.n_regionkey = region_1.r_regionkey)
                             ->  Seq Scan on region region_1
                                   Filter: (r_name = 'AMERICA'::bpchar)
                             ->  Nested Loop
                                   ->  Nested Loop
                                         ->  Index Scan using idx_partsupp_partkey on partsupp partsupp_1
                                               Index Cond: (part.p_partkey = ps_partkey)
                                         ->  Index Scan using supplier_pkey on supplier supplier_1
                                               Index Cond: (s_suppkey = partsupp_1.ps_suppkey)
                                   ->  Index Scan using nation_pkey on nation nation_1
                                         Index Cond: (n_nationkey = supplier_1.s_nationkey)

「Merge Join」ノヌドは「Gather Merge」の䞊にありたす。 したがっお、マヌゞでは䞊列凊理は䜿甚されたせん。 ただし、「Parallel Index Scan」ノヌドは䟝然ずしおセグメントに圹立ちたす。 part_pkey.

セクションごずの接続

PostgreSQL 11 では セクションごずの接続 デフォルトでは無効になっおいたす。非垞に負荷の高いスケゞュヌリングが必芁です。 同様のパヌティション分割を持぀テヌブルは、パヌティションごずに結合できたす。 このようにしお、Postgres はより小さなハッシュ テヌブルを䜿甚したす。 セクションの各接続は䞊列にするこずができたす。

tpch=# set enable_partitionwise_join=t;
tpch=# explain (costs off) select * from prt1 t1, prt2 t2
where t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;
                    QUERY PLAN
---------------------------------------------------
 Append
   ->  Hash Join
         Hash Cond: (t2.b = t1.a)
         ->  Seq Scan on prt2_p1 t2
               Filter: ((b >= 0) AND (b <= 10000))
         ->  Hash
               ->  Seq Scan on prt1_p1 t1
                     Filter: (b = 0)
   ->  Hash Join
         Hash Cond: (t2_1.b = t1_1.a)
         ->  Seq Scan on prt2_p2 t2_1
               Filter: ((b >= 0) AND (b <= 10000))
         ->  Hash
               ->  Seq Scan on prt1_p2 t1_1
                     Filter: (b = 0)
tpch=# set parallel_setup_cost = 1;
tpch=# set parallel_tuple_cost = 0.01;
tpch=# explain (costs off) select * from prt1 t1, prt2 t2
where t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;
                        QUERY PLAN
-----------------------------------------------------------
 Gather
   Workers Planned: 4
   ->  Parallel Append
         ->  Parallel Hash Join
               Hash Cond: (t2_1.b = t1_1.a)
               ->  Parallel Seq Scan on prt2_p2 t2_1
                     Filter: ((b >= 0) AND (b <= 10000))
               ->  Parallel Hash
                     ->  Parallel Seq Scan on prt1_p2 t1_1
                           Filter: (b = 0)
         ->  Parallel Hash Join
               Hash Cond: (t2.b = t1.a)
               ->  Parallel Seq Scan on prt2_p1 t2
                     Filter: ((b >= 0) AND (b <= 10000))
               ->  Parallel Hash
                     ->  Parallel Seq Scan on prt1_p1 t1
                           Filter: (b = 0)

重芁なこずは、セクション内の接続が䞊列になるのは、これらのセクションが十分に倧きい堎合のみであるずいうこずです。

䞊列远加

䞊列远加 異なるワヌクフロヌの異なるブロックの代わりに䜿甚できたす。 これは通垞、UNION ALL ク゚リで発生したす。 欠点は、各ワヌカヌ プロセスが 1 ぀のリク゚ストのみを凊理するため、䞊列凊理が少ないこずです。

ここでは 2 ぀のワヌカヌ プロセスが実行されおいたすが、4 ぀が有効になっおいたす。

tpch=# explain (costs off) select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day union all select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '2000-12-01' - interval '105' day;
                                           QUERY PLAN
------------------------------------------------------------------------------------------------
 Gather
   Workers Planned: 2
   ->  Parallel Append
         ->  Aggregate
               ->  Seq Scan on lineitem
                     Filter: (l_shipdate <= '2000-08-18 00:00:00'::timestamp without time zone)
         ->  Aggregate
               ->  Seq Scan on lineitem lineitem_1
                     Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)

最も重芁な倉数

  • WORK_MEM はク゚リだけでなくプロセスごずのメモリを制限したす: work_mem プロセス 接続 = 倧量のメモリ。
  • max_parallel_workers_per_gather — 実行䞭のプログラムが蚈画からの䞊列凊理に䜿甚するワヌカヌ プロセスの数。
  • max_worker_processes — ワヌカヌ プロセスの合蚈数をサヌバヌ䞊の CPU コアの数に調敎したす。
  • max_parallel_workers - 同じですが、䞊列䜜業プロセスの堎合です。

結果

バヌゞョン 9.6 では、䞊列凊理により、倚数の行たたはむンデックスをスキャンする耇雑なク゚リのパフォヌマンスが倧幅に向䞊したす。 PostgreSQL 10 では、䞊列凊理がデフォルトで有効になっおいたす。 OLTP ワヌクロヌドが倧きいサヌバヌでは、必ず無効にしおください。 順次スキャンたたはむンデックス スキャンは倧量のリ゜ヌスを消費したす。 デヌタセット党䜓に察しおレポヌトを実行しおいない堎合は、䞍足しおいるむンデックスを远加するか、適切なパヌティショニングを䜿甚するだけで、ク゚リのパフォヌマンスを向䞊させるこずができたす。

リファレンス

出所 habr.com

コメントを远加したす