query plan

Started by Torsten Förtschover 2 years ago2 messagesgeneral
Jump to latest
#1Torsten Förtsch
tfoertsch123@gmail.com

Hi,

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 query involved way further down a partitioned table with 2 partitions,
one pretty big in the 1e9 rows range, the other practically empty. The big
partition had been analyzed before. But the partitioned table and the empty
partition never. After analyzing them all was well.

I am just curious to understand how that number is calculated.

This is PG14.

Thanks.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Torsten Förtsch (#1)
Re: query plan

=?UTF-8?Q?Torsten_F=C3=B6rtsch?= <tfoertsch123@gmail.com> 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