On Mon, May 9, 2016 at 11:11 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
I agree. >> 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. Hmm, that is strange. I would have expected that to stuff a Gather on top of the Aggregate. I wonder why it's not doing that. > 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? That seems reasonable to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
