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

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

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 ?

gnari

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Matt Casters 2005-01-20 09:34:35
Previous Message Ragnar Hafstað 2005-01-20 09:23:58 Re: index scan of whole table, can't see why