Re: Slow query

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Ivan Voras <ivoras(at)fer(dot)hr>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Slow query
Date: 2004-03-01 16:26:50
Message-ID: Pine.LNX.4.33.0403010923120.32148-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

In response to

  • Slow query at 2004-02-24 13:17:18 from Ivan Voras

Browse pgsql-performance by date

  From Date Subject
Next Message Rob Fielding 2004-03-01 17:30:41 Re: WAL Optimisation - configuration and usage
Previous Message Anjan Dave 2004-03-01 15:35:30 Scaling further up