Re: index scan of whole table, can't see why - Mailing list pgsql-performance

From Dan Langille
Subject Re: index scan of whole table, can't see why
Date
Msg-id 41EF7C85.4180.D46F54D@localhost
Whole thread Raw
In response to Re: index scan of whole table, can't see why  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: index scan of whole table, can't see why
List pgsql-performance
On 20 Jan 2005 at 6:14, Stephan Szabo wrote:

> On Wed, 19 Jan 2005, Dan Langille wrote:
>
> > Hi folks,
> >
> > Running on 7.4.2, recently vacuum analysed the three tables in
> > question.
> >
> > The query plan in question changes dramatically when a WHERE clause
> > changes from ports.broken to ports.deprecated.  I don't see why.
> > Well, I do see why: a sequential scan of a 130,000 rows.  The query
> > goes from 13ms to 1100ms because the of this.  The full plans are at
> > http://rafb.net/paste/results/v8ccvQ54.html
> >
> > I have tried some tuning by:
> >
> >   set effective_cache_size to 4000, was 1000
> >   set random_page_cost to 1, was 4
> >
> > The resulting plan changes, but no speed improvment, are at
> > http://rafb.net/paste/results/rV8khJ18.html
> >
> > Any suggestions please?
>
> As a question, what does it do if enable_hashjoin is false? I'm wondering
> if it'll pick a nested loop for that step for the element/ports join and
> what it estimates the cost to be.

With enable_hashjoin = false, no speed improvement.  Execution plan
at http://rafb.net/paste/results/qtSFVM72.html

thanks
--
Dan Langille : http://www.langille.org/
BSDCan - The Technical BSD Conference - http://www.bsdcan.org/


pgsql-performance by date:

Previous
From: Hervé Piedvache
Date:
Subject: Re: PostgreSQL clustering VS MySQL clustering
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: PostgreSQL clustering VS MySQL clustering