Re: Instability in partition_prune test?

On 13 April 2018 at 14:37, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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