On Tue, 24 Feb 2004, Ivan Voras wrote: > -> Nested Loop (cost=1.04..788.76 rows=3 width=500) (actual > time=4078.85..20185.89 rows=38999 loops=1) > -> Nested Loop (cost=1.04..771.27 rows=3 width=485) > (actual time=4078.71..14673.27 rows=38999 loops=1) > -> Nested Loop (cost=0.00..752.16 rows=195 > width=288) (actual time=4078.20..6702.17 rows=38999 loops=1) > -> Nested Loop > (cost=0.00..748.72 rows=195 width=184) (actual time=0.21..3197.16 > rows=38999 loops=1)
Note those nested loops up there. They think that you are going to be operating on 3,3,195, and 195 rows respectively, when they actually are operating on 38999, 38999, 38999, and 38999 in reality. set enable_nestloop = off and see if that helps. If so, see if altering the responsible columns default stats to something higher (100 is a good start) and reanalyze to see if you get a better plan. As long as those estimates are that far off, you're gonna get a poorly performing query when the planner is allowed to use nested loops. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings