Re: sub select performance due to seq scans

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: sub select performance due to seq scans
Дата
Msg-id 14463.1154356126@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: sub select performance due to seq scans  (H Hale <hhale21@rogers.com>)
Ответы Re: sub select performance due to seq scans  (H Hale <hhale21@rogers.com>)
Список pgsql-performance
H Hale <hhale21@rogers.com> writes:
>     ->  Bitmap Heap Scan on flatomfilesysentry  (cost=2.00..274.38 rows=3238 width=30) (actual time=0.011..0.013
rows=1loops=6473) 
>           Recheck Cond: (flatomfilesysentry.objectid = "outer".dstobj)
>           ->  Bitmap Index Scan on flatomfilesysentry_pkey  (cost=0.00..2.00 rows=3238 width=0) (actual
time=0.007..0.007rows=1 loops=6473) 
>                 Index Cond: (flatomfilesysentry.objectid = "outer".dstobj)

Well, there's our estimation failure: 3238 rows expected, one row
actual.

What is the data distribution of flatomfilesysentry.objectid?
It looks from this example like it is unique or nearly so,
but the planner evidently does not think that.

            regards, tom lane

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

Предыдущее
От: H Hale
Дата:
Сообщение: Re: sub select performance due to seq scans
Следующее
От: Axel Rau
Дата:
Сообщение: Re: directory tree query with big planner variation