PostgreSQL not using HashAgg for UNION queries

Question

I'm using psql 9.2.3. I have two very large tables t1 and t2 with many duplicates:

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

I'm now trying to use UNION to merge and deduplicate these tables. According to SQL UNION Question , Postgresql should try to use HashAgg for best performance. However, when I tried the same query EXPLAIN SELECT * FROM t1 UNION SELECT * FROM t2 on my tables, Postgres always tries a sort-based algorithm:

                                    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)

and generates unbearably slow query plans. I have set the enable_hashagg parameter to ON :

db=# SET enable_hashagg=ON;
SET

How can I force PostgreSQL to use hashAgg algorithms?

Also, is there a way to tell PostgreSQL to use hashAgg for DISTINCT and other set operators involving DISTINCT like EXCEPT ?

Solution

Craig's answer works very well. After setting the work_mem parameter, PostgreSQL generates the desired plan:

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)

whereas

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)

Answer 1

SET enable_hashagg = on has no effect; that's the default. Those parameters are used to force PostgreSQL to use a given method only as a last resort by setting it to off , and they're really on there for testing and development.

Raising work_mem dramatically may encourage the choice of a hashagg plan. You might also want to fiddle with random_page_cost and seq_page_cost , and make sure that effective_cache_size reflects the system's available memory.