1

psql 9.2.3 を使用しています。2 つの非常に大きなテーブルがt1ありt2、多くの重複があります。

  • SELECT COUNT(*) FROM t1= 37,792,210
  • SELECT COUNT(*) FROM t2= 73,464,030

私は現在UNION、これらのテーブルをマージして重複排除するために使用しようとしています。SQL UNION Questionによると、Postgresql はHashAgg最高のパフォーマンスを得るために使用を試みる必要があります。ただし、テーブルで同じクエリを試行するとEXPLAIN SELECT * FROM t1 UNION SELECT * FROM t2、Postgres は常に並べ替えベースのアルゴリズムを試行します。

                                    QUERY PLAN                                    
----------------------------------------------------------------------------------
 Unique  (cost=29210659.24..30879489.76 rows=111255368 width=20)
   ->  Sort  (cost=29210659.24..29488797.66 rows=111255368 width=20)
         Sort Key: t1.col1, t1.col2, t1.col3, t1.col4, t1.col5
         ->  Append  (cost=0.00..2933746.36 rows=111255368 width=20)
               ->  Seq Scan on t1  (cost=0.00..618633.96 rows=37791896 width=20)
               ->  Seq Scan on t2  (cost=0.00..1202558.72 rows=73463472 width=20)

耐えられないほど遅いクエリ プランを生成します。enable_hashaggパラメータをON次のように設定しました。

db=# SET enable_hashagg=ON;
SET

PostgreSQL に hashAgg アルゴリズムを強制的に使用させるにはどうすればよいですか?

また、PostgreSQL に hashAgg for および like を含むその他の集合演算子を使用するように指示する方法はありますDISTINCTか?DISTINCTEXCEPT

解決

クレイグの答えは非常にうまく機能します。work_memパラメータを設定した後、PostgreSQL は目的のプランを生成します。

EXPLAIN ANALYZE
  SELECT * FROM t1 UNION SELECT * FROM t2 UNION SELECT * FROM t3 UNION
  SELECT * FROM t4 UNION SELECT * FROM t5 UNION SELECT * FROM t6;
                                                            QUERY PLAN                                                            
----------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=7205428.09..9062949.04 rows=185752095 width=20) (actual time=324868.512..327072.616 rows=3379701 loops=1)
   ->  Append  (cost=0.00..4883526.90 rows=185752095 width=20) (actual time=13.537..175073.860 rows=183451688 loops=1)
         ->  Seq Scan on t1  (cost=0.00..25912.73 rows=1582973 width=20) (actual time=13.536..554.381 rows=1582973 loops=1)
         ->  Seq Scan on t2  (cost=0.00..9204.29 rows=562229 width=20) (actual time=0.293..128.485 rows=562229 loops=1)
         ->  Seq Scan on t3  (cost=0.00..618633.96 rows=37791896 width=20) (actual time=20.919..41062.926 rows=37792210 loops=1)
         ->  Seq Scan on t4  (cost=0.00..1202558.72 rows=73463472 width=20) (actual time=26.689..50081.367 rows=73464030 loops=1)
         ->  Seq Scan on t5  (cost=0.00..161043.91 rows=9838091 width=20) (actual time=9.930..4548.116 rows=9837957 loops=1)
         ->  Seq Scan on t6  (cost=0.00..1008652.34 rows=62513434 width=20) (actual time=38.144..52663.002 rows=60212289 loops=1)
 Total runtime: 328914.575 ms (5.5 min)

一方

SET enable_hashagg=OFF;
SET
EXPLAIN ANALYZE
  SELECT * FROM t1 UNION SELECT * FROM t2 UNION SELECT * FROM t3 UNION
  SELECT * FROM t4 UNION SELECT * FROM t5 UNION SELECT * FROM t6;

                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 Unique  (cost=33779086.16..36530850.99 rows=183450989 width=20) (actual time=1372760.630..1569685.807 rows=3379701 loops=1)
   ->  Sort  (cost=33779086.16..34237713.63 rows=183450989 width=20) (actual time=1372760.628..1528232.239 rows=183451688 loops=1)
         Sort Key: t1.col1, t1.col2, t1.col3, t1.col4, t1.col5
         Sort Method: external merge  Disk: 5379792kB
         ->  Append  (cost=0.00..4837504.78 rows=183450989 width=20) (actual time=14.780..98779.365 rows=183451688 loops=1)
               ->  Seq Scan on t1  (cost=0.00..25912.73 rows=1582973 width=20) (actual time=14.777..389.774 rows=1582973 loops=1)
               ->  Seq Scan on t2  (cost=0.00..9204.29 rows=562229 width=20) (actual time=4.994..137.951 rows=562229 loops=1)
               ->  Seq Scan on t3  (cost=0.00..618633.96 rows=37791896 width=20) (actual time=12.028..16287.735 rows=37792210 loops=1)
               ->  Seq Scan on t4  (cost=0.00..1202558.72 rows=73463472 width=20) (actual time=51.791..33784.820 rows=73464030 loops=1)
               ->  Seq Scan on t5  (cost=0.00..161043.91 rows=9838091 width=20) (actual time=26.564..3206.521 rows=9837957 loops=1)
               ->  Seq Scan on t6  (cost=0.00..985641.28 rows=60212328 width=20) (actual time=22.941..20808.849 rows=60212289 loops=1)
 Total runtime: 1570609.508 ms (26.2 min)
4

1 に答える 1

2

SET enable_hashagg = on効果はありません。それがデフォルトです。これらのパラメータは、特定のメソッドを に設定することにより、PostgreSQL が特定のメソッドを最後の手段としてのみ使用するように強制するために使用されoff、テストと開発のために実際に使用されます。

大幅な資金調達work_memは、ハシャッグ プランの選択を促す可能性があります。random_page_costまた、とをいじって、システムの使用可能なメモリが反映さseq_page_costれていることを確認することもできます。effective_cache_size

于 2013-06-27T04:04:31.750 に答える