Tomas Vondra <[email protected]> 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=100 width=8)
Hash Cond: ((pp.f1 = cc.f1) AND (pp.f2 = cc.f2))
-> Append (cost=0.00..8614.96 rows=417996 width=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=1000000 width=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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
