Andres Freund <and...@anarazel.de> writes:
> I think it's a good idea to run a force-parallel run on some buildfarm
> members.
Noah's already doing that on at least one of his critters. But some more
wouldn't hurt.
> But I'm rather convinced that the core tests run by all animals
> need some minimal coverage of parallel queries. Both because otherwise
> it'll be hard to get some coverage of unusual platforms, and because
> it's imo something rather relevant to test during development.
+1. Experimenting with what we might do, it seems like it's harder to get
the planner to use a parallel plan than you would think.
regression=# explain select count(*) from tenk1;
QUERY PLAN
--------------------------------------------------------------------------------
-------------------
Aggregate (cost=295.29..295.30 rows=1 width=8)
-> Index Only Scan using tenk1_thous_tenthous on tenk1 (cost=0.29..270.29 r
ows=10000 width=0)
(2 rows)
regression=# set enable_indexscan TO 0;
SET
regression=# explain select count(*) from tenk1;
QUERY PLAN
-----------------------------------------------------------------
Aggregate (cost=483.00..483.01 rows=1 width=8)
-> Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=0)
(2 rows)
regression=# set force_parallel_mode TO on;
SET
regression=# explain select count(*) from tenk1;
QUERY PLAN
-----------------------------------------------------------------
Aggregate (cost=483.00..483.01 rows=1 width=8)
-> Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=0)
(2 rows)
Methinks force_parallel_mode is a bit broken.
Also, once you *do* get it to make a parallel plan:
regression=# create table foo as select generate_series(1,1000000) g;
SELECT 1000000
regression=# analyze foo;
ANALYZE
regression=# explain select count(*) from foo;
QUERY PLAN
--------------------------------------------------------------------------------------
Finalize Aggregate (cost=10633.55..10633.56 rows=1 width=8)
-> Gather (cost=10633.33..10633.54 rows=2 width=8)
Workers Planned: 2
-> Partial Aggregate (cost=9633.33..9633.34 rows=1 width=8)
-> Parallel Seq Scan on foo (cost=0.00..8591.67 rows=416667
width=0)
(5 rows)
regression=# explain (costs off) select count(*) from foo;
QUERY PLAN
--------------------------------------------
Finalize Aggregate
-> Gather
Workers Planned: 2
-> Partial Aggregate
-> Parallel Seq Scan on foo
(5 rows)
That's not going to do for a regression-test case because it will break
anytime somebody changes the value of max_parallel_degree. Maybe we
should suppress the "Workers Planned" field in costs-off display mode?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
