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

From: "Dan Langille" <dan(at)langille(dot)org>
To: Ragnar Hafstað <gnari(at)simnet(dot)is>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: index scan of whole table, can't see why
Date: 2005-01-20 11:56:20
Message-ID: 41EF5614.28069.CB0CC42@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 20 Jan 2005 at 9:34, Ragnar Hafstað wrote:

> On Wed, 2005-01-19 at 20:37 -0500, 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
> >
>
> this just confirms that an indexscan is not always better than a
> tablescan. by setting random_page_cost to 1, you deceiving the
> planner into thinking that the indexscan is almost as effective
> as a tablescan.
>
> > Any suggestions please?
>
> did you try to increase sort_mem ?

I tried sort_mem = 4096 and then 16384. This did not make a
difference. See http://rafb.net/paste/results/AVDqEm55.html

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Richard Huxton 2005-01-20 12:10:59 Re: [SQL] OFFSET impact on Performance???
Previous Message Andrei Bintintan 2005-01-20 11:13:44 OFFSET impact on Performance???