query plan

Поиск
Список
Период
Сортировка
От Torsten Förtsch
Тема query plan
Дата
Msg-id CAKkG4_kD_H0F81EX8585RQu99pMeUQ5Ra17-AX0o7ToZ2bMaOA@mail.gmail.com
обсуждение исходный текст
Ответы Re: query plan
Список pgsql-general
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.

В списке pgsql-general по дате отправления:

Предыдущее
От: Juan Rodrigo Alejandro Burgos Mella
Дата:
Сообщение: Re: Trigger to Count Number of Logical Replication Table Changes.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: query plan