Skip site navigation (1) Skip section navigation (2)

Re: index scan of whole table, can't see why

From: "Dan Langille" <dan(at)langille(dot)org>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: index scan of whole table, can't see why
Date: 2005-01-20 15:36:04
Message-ID: 41EF8994.24822.D79F9C9@localhost (view raw or flat)
Thread:
Lists: pgsql-performance
On 20 Jan 2005 at 7:26, Stephan Szabo wrote:

> On Thu, 20 Jan 2005, Dan Langille wrote:
> 
> > 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
> 
> Honestly I expected it to be slower (which it was), but I figured it's
> worth seeing what alternate plans it'll generate (specifically to see how
> it cost a nested loop on that join to compare to the fast plan).
> Unfortunately, it generated a merge join, so I think it might require both
> enable_hashjoin=false and enable_mergejoin=false to get it which is likely
> to be even slower in practice but still may be useful to see.

Setting both to false gives a dramatic performance boost.  See 
http://rafb.net/paste/results/b70KAi42.html

This gives suitable speed, but why does the plan vary so much with 
such a minor change in the WHERE clause?
-- 
Dan Langille : http://www.langille.org/
BSDCan - The Technical BSD Conference - http://www.bsdcan.org/


In response to

Responses

pgsql-performance by date

Next:From: Steve WamplerDate: 2005-01-20 15:40:04
Subject: Re: PostgreSQL clustering VS MySQL clustering
Previous:From: Hervé PiedvacheDate: 2005-01-20 15:32:27
Subject: Re: PostgreSQL clustering VS MySQL clustering

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group