Re: Instability in partition_prune test?

On 13 April 2018 at 14:37, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
> I think it might be working as designed!  The participants are allowed
> to run other subplans, because they're parallel sub-plans: it's just a
> question of whether any backend manages to complete its subplan and
> then go looking for another subplan to attack before it is marked as
> complete.  If that's true, then the loop number shown can't
> technically be made stable, can it?  Unless you make it so that the
> scans were not allowed to be run by more than one worker.

Yeah, you're right.

It's pretty easy to show this by giving Parallel Append a small
subnode and a larger subnode to work on:

drop table if exists t1;
drop table if exists t2;
create table t1 (a int);
create table t2 (a int);
insert into t1 select generate_Series(1,1000000);
insert into t2 select generate_Series(1,10000);

explain (analyze, costs off, summary off, timing off) select count(*)
from (select * from t1 union all select * from t2) t1_t2;
                                  QUERY PLAN
------------------------------------------------------------------------------
 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather (actual rows=3 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         ->  Partial Aggregate (actual rows=1 loops=3)
               ->  Parallel Append (actual rows=336667 loops=3)
                     ->  Parallel Seq Scan on t1 (actual rows=333333 loops=3)
                     ->  Parallel Seq Scan on t2 (actual rows=10000 loops=1)
(8 rows)

I'll just need to go think about how we can make the test stable now.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services