Robert Haas <robertmh...@gmail.com> writes:
> On Mon, May 9, 2016 at 11:11 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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.
The reason is that create_plain_partial_paths() contains a hard-wired
decision not to generate any partial paths for relations smaller than
1000 blocks, which means that no partial path will ever be generated
for *any* relation in the standard regression tests, force_parallel_mode
or no.
I would just go fix this, along the lines of
*************** create_plain_partial_paths(PlannerInfo *
*** 702,708 ****
* with all of its inheritance siblings it may well pay off.
*/
if (rel->pages < parallel_threshold &&
! rel->reloptkind == RELOPT_BASEREL)
return;
/*
--- 703,710 ----
* with all of its inheritance siblings it may well pay off.
*/
if (rel->pages < parallel_threshold &&
! rel->reloptkind == RELOPT_BASEREL &&
! force_parallel_mode == FORCE_PARALLEL_OFF)
return;
/*
except that doing so and running the regression tests with
force_parallel_mode = on results in core dumps. Some debugging seems
indicated ... and we should at this point assume that there has been no
useful testing of parallel query in the buildfarm, not even on Noah's
machines.
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
