Re: plan_rows confusion with parallel queries

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> while eye-balling some explain plans for parallel queries, I got a bit
> confused by the row count estimates. I wonder whether I'm alone.

I got confused by that a minute ago, so no you're not alone.  The problem
is even worse in join cases.  For example:
Gather  (cost=34332.00..53265.35 rows=100 width=8)  Workers Planned: 2  ->  Hash Join  (cost=33332.00..52255.35
rows=100width=8)        Hash Cond: ((pp.f1 = cc.f1) AND (pp.f2 = cc.f2))        ->  Append  (cost=0.00..8614.96
rows=417996width=8)              ->  Parallel Seq Scan on pp  (cost=0.00..8591.67 rows=416667 widt 
h=8)              ->  Parallel Seq Scan on pp1  (cost=0.00..23.29 rows=1329 width=8
)        ->  Hash  (cost=14425.00..14425.00 rows=1000000 width=8)              ->  Seq Scan on cc  (cost=0.00..14425.00
rows=1000000width=8) 

There are actually 1000000 rows in pp, and none in pp1.  I'm not bothered
particularly by the nonzero estimate for pp1, because I know where that
came from, but I'm not very happy that nowhere here does it look like
it's estimating a million-plus rows going into the join.
        regards, tom lane