Re: Very slow left outer join
От | Michael Glaesemann |
---|---|
Тема | Re: Very slow left outer join |
Дата | |
Msg-id | D140B279-DAD1-479C-9E5B-557D575D9CC4@seespotcode.net обсуждение исходный текст |
Ответ на | Very slow left outer join ("Tyrrill, Ed" <tyrrill_ed@emc.com>) |
Ответы |
Re: Very slow left outer join
|
Список | pgsql-performance |
On May 29, 2007, at 19:16 , Tyrrill, Ed wrote: > ----- > Hash Join (cost=361299.50..1054312.92 rows=34805 width=8) (actual > time=1446.861..368723.597 rows=2789 loops=1) > Hash Cond: ("outer".record_id = "inner".record_id) > -> Seq Scan on backupobjects (cost=0.00..429929.79 rows=13136779 > width=8) (actual time=5.165..359168.216 rows=13136779 loops=1) > -> Hash (cost=360207.21..360207.21 rows=436915 width=8) (actual > time=820.979..820.979 rows=2789 loops=1) > -> Bitmap Heap Scan on backup_location > (cost=3831.20..360207.21 rows=436915 width=8) (actual > time=797.463..818.269 rows=2789 loops=1) > Recheck Cond: (backup_id = 1071) > -> Bitmap Index Scan on backup_location_bid > (cost=0.00..3831.20 rows=436915 width=0) (actual time=59.592..59.592 > rows=2789 loops=1) Off the cuff, when was the last time you vacuumed or ran ANALYZE? Your row estimates look off by a couple orders of magnitude. With up- to-date statistics the planner might do a better job. As for any other improvements, I'll leave that to those that know more than I. :) Michael Glaesemann grzm seespotcode net
В списке pgsql-performance по дате отправления: