From: Gary Stainburn <gary.stainburn@ringways.co.uk>
Organization: Ringways Garages Ltd
To: pgsql-sql@postgresql.org
Subject: Re: select slows from 3 seconds to 30 seconds
Date: Tue, 8 May 2007 11:08:18 +0100
User-Agent: KMail/1.9.5
References: <200705041649.54193.gary.stainburn@ringways.co.uk>
	<12822.1178326627@sss.pgh.pa.us>
In-Reply-To: <12822.1178326627@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200705081108.18881.gary.stainburn@ringways.co.uk>

On Saturday 05 May 2007 01:57, Tom Lane wrote:
> Gary Stainburn <gary.stainburn@ringways.co.uk> writes:
> > I have the query below which when run takes approx 3 seconds.  However
> > when I add the condition 'and w_ws_id = 10' onto the end changes to 30+
> > seconds. Can anyone see why? I've included the explain for the long
> > select.
>
> You really ought to provide EXPLAIN ANALYZE output for both versions if
> you want intelligent commentary --- otherwise we're just guessing.
>
> But I would guess the problem is that the planner is way off about the
>
> number of rows satisfying the joint condition --- it thinks two:
> >                            ->  Index Scan using walon_hide_index on walon
> >  (cost=0.00..85.04 rows=2 width=140) Index Cond: (w_hide = 0)
> >                                  Filter: (w_ws_id = 10)
>
> This plan is good if there really are only a couple rows, but degrades
> quickly if there are many...
>
> 			regards, tom lane

Thanks Tom

I'll bear that in mind in future.

The problem was fixed by running a 'vacuum analyse' so it looks like the 
planner was getting confused.

Gary


-- 
Gary Stainburn
 
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000