Re: sub select performance due to seq scans

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: sub select performance due to seq scans
Дата
Msg-id 13708.1154350414@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: sub select performance due to seq scans  (Rod Taylor <rbt@rbt.ca>)
Список pgsql-performance
Rod Taylor <rbt@rbt.ca> writes:
>> Nested Loop IN Join  (cost=0.00..1386.45 rows=5809 width=14) (actual
>> time=2.933..101467.463 rows=5841 loops=1)
>> Join Filter: ("outer".objectid = "inner".dstobj)
>> ->  Seq Scan on flatomfilesysentry  (cost=0.00..368.09 rows=5809
>> width=30) (actual time=0.007..23.451 rows=5844 loops=1)
>> ->  Seq Scan on flatommemberrelation  (cost=0.00..439.05 rows=5842
>> width=16) (actual time=0.007..11.790 rows=2922 loops=5844)

> A loop for an IN indicates that you are using a very old version of
> PostgreSQL (7.2 or earlier).

No, it's not that, because 7.2 certainly had no idea of "IN Join"s.
But there's something mighty fishy about this plan anyway.  The
planner was predicting 5809 rows out from flatomfilesysentry (not
too far off), so why didn't it predict something north of
368.09 + 5809 * 439.05 as the total join cost?  There's a special case
in cost_nestloop for IN joins, but it sure shouldn't have reduced the
estimate by a factor of 1800+ ...

            regards, tom lane

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

Предыдущее
От: Jonathan Ballet
Дата:
Сообщение: Performances with new Intel Core* processors
Следующее
От: Michael Stone
Дата:
Сообщение: Re: directory tree query with big planner variation