gpt4 book ai didi

sql - PostgreSQL 不使用 HashAgg 进行 UNION 查询

转载 作者:行者123 更新时间:2023-11-29 13:04:42 24 4
gpt4 key购买 nike

我正在使用 psql 9.2.3。我有两个非常大的表 t1t2 有很多重复项:

  • 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 对 DISTINCT 和其他涉及 DISTINCT 的集合运算符(如 EXCEPT)使用 hashAgg?

解决方案

Craig 的回答非常有效。设置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)

最佳答案

SET enable_hashagg = on 无效;这是默认设置。这些参数用于通过将给定方法设置为 off 来强制 PostgreSQL 仅在万不得已时使用给定方法,并且它们确实用于测试和开发。

大幅提高 work_mem 可能会鼓励选择 hashagg 计划。您可能还想摆弄 random_page_costseq_page_cost,并确保 effective_cache_size 反射(reflect)系统的可用内存。

关于sql - PostgreSQL 不使用 HashAgg 进行 UNION 查询,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17334100/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com