=?UTF-8?Q?Torsten_F=C3=B6rtsch?= <tfoertsch123@xxxxxxxxx> writes: > This is part of a query plan: > Nested Loop Left Join (cost=26.32..47078866.36 rows=1344945195 width=626) > -> Nested Loop Left Join (cost=25.74..5312.48 rows=1344945195 > width=608) > -> Nested Loop Left Join (cost=6.79..2876.77 rows=102 width=373) > -> Nested Loop Left Join (cost=1.90..1965.51 rows=102 > width=361) > -> Bitmap Heap Scan on ... (cost=4.89..8.91 rows=2 > width=28) > -> Hash Left Join (cost=18.95..42.61 rows=3 width=243) > -> Hash Left Join (cost=18.94..42.59 rows=3 width=203) > -> Hash (cost=0.00..0.00 rows=1 width=48) > -> Memoize (cost=0.58..4.59 rows=1 width=172) > What I don't understand is this. The left node of the join is expected to > return 102 rows. The right node 3. How can this result in >1e9 rows? The rowcount estimate for the join is not derived by multiplying the rowcount estimates of the two inputs. Having said that, this looks pretty inconsistent. Can you show a test case that acts like that? regards, tom lane
