Tomas Vondra <tomas.von...@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=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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers