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.
