diff options
author | David Rowley | 2021-08-22 11:31:16 +0000 |
---|---|---|
committer | David Rowley | 2021-08-22 11:31:16 +0000 |
commit | 22c4e88ebff408acd52e212543a77158bde59e69 (patch) | |
tree | 41b320c366b66ca4fa724259e79b4ceb2a696d2d /src/test/regress/expected/select_distinct.out | |
parent | 26ae66090398082c54ce046936fc41633dbfc41e (diff) |
Allow parallel DISTINCT
We've supported parallel aggregation since e06a38965. At the time, we
didn't quite get around to also adding parallel DISTINCT. So, let's do
that now.
This is implemented by introducing a two-phase DISTINCT. Phase 1 is
performed on parallel workers, rows are made distinct there either by
hashing or by sort/unique. The results from the parallel workers are
combined and the final distinct phase is performed serially to get rid of
any duplicate rows that appear due to combining rows for each of the
parallel workers.
Author: David Rowley
Reviewed-by: Zhihong Yu
Discussion: https://postgr.es/m/CAApHDvrjRxVKwQN0he79xS+9wyotFXL=RmoWqGGO2N45Farpgw@mail.gmail.com
Diffstat (limited to 'src/test/regress/expected/select_distinct.out')
-rw-r--r-- | src/test/regress/expected/select_distinct.out | 67 |
1 files changed, 67 insertions, 0 deletions
diff --git a/src/test/regress/expected/select_distinct.out b/src/test/regress/expected/select_distinct.out index 11c6f50fbfa..0c8e10f88a5 100644 --- a/src/test/regress/expected/select_distinct.out +++ b/src/test/regress/expected/select_distinct.out @@ -210,6 +210,73 @@ DROP TABLE distinct_hash_1; DROP TABLE distinct_hash_2; DROP TABLE distinct_group_1; DROP TABLE distinct_group_2; +-- Test parallel DISTINCT +SET parallel_tuple_cost=0; +SET parallel_setup_cost=0; +SET min_parallel_table_scan_size=0; +-- Ensure we get a parallel plan +EXPLAIN (costs off) +SELECT DISTINCT four FROM tenk1; + QUERY PLAN +---------------------------------------------------- + Unique + -> Sort + Sort Key: four + -> Gather + Workers Planned: 2 + -> HashAggregate + Group Key: four + -> Parallel Seq Scan on tenk1 +(8 rows) + +-- Ensure the parallel plan produces the correct results +SELECT DISTINCT four FROM tenk1; + four +------ + 0 + 1 + 2 + 3 +(4 rows) + +CREATE OR REPLACE FUNCTION distinct_func(a INT) RETURNS INT AS $$ + BEGIN + RETURN a; + END; +$$ LANGUAGE plpgsql PARALLEL UNSAFE; +-- Ensure we don't do parallel distinct with a parallel unsafe function +EXPLAIN (COSTS OFF) +SELECT DISTINCT distinct_func(1) FROM tenk1; + QUERY PLAN +---------------------------------------------------------- + Unique + -> Sort + Sort Key: (distinct_func(1)) + -> Index Only Scan using tenk1_hundred on tenk1 +(4 rows) + +-- make the function parallel safe +CREATE OR REPLACE FUNCTION distinct_func(a INT) RETURNS INT AS $$ + BEGIN + RETURN a; + END; +$$ LANGUAGE plpgsql PARALLEL SAFE; +-- Ensure we do parallel distinct now that the function is parallel safe +EXPLAIN (COSTS OFF) +SELECT DISTINCT distinct_func(1) FROM tenk1; + QUERY PLAN +---------------------------------------------- + Unique + -> Sort + Sort Key: (distinct_func(1)) + -> Gather + Workers Planned: 2 + -> Parallel Seq Scan on tenk1 +(6 rows) + +RESET min_parallel_table_scan_size; +RESET parallel_setup_cost; +RESET parallel_tuple_cost; -- -- Also, some tests of IS DISTINCT FROM, which doesn't quite deserve its -- very own regression file. |