Re: why my query is not using index?? - Mailing list pgsql-performance

From John Meinel
Subject Re: why my query is not using index??
Date
Msg-id 416B217D.9090000@johnmeinel.com
Whole thread Raw
In response to Re: why my query is not using index??  (Francisco Reyes <lists@natserv.com>)
Responses Re: why my query is not using index??  (Greg Stark <gsstark@mit.edu>)
Re: why my query is not using index??  (Francisco Reyes <lists@natserv.com>)
List pgsql-performance
Francisco Reyes wrote:
> On Mon, 11 Oct 2004, Janning Vygen wrote:
>
[...]
> When I saw the default explain I was surprised to see that indexes were
> not been used. For example the join on lines 4,5 are exactly the primary
> key of the tables yet a sequential scan was used.
>

Note this:
> The default explain was:
>
> Sort  (cost=382.01..382.15 rows=56 width=196)
>    Sort Key: accounts.account_group, accounts.account_name,

[...]

Versus this:
>
> After set enable_seqscan to off;
> It becomes
>
> Sort  (cost=490.82..490.96 rows=56 width=196)
>    Sort Key: accounts.account_group, accounts.account_name,

[...]

Postgres believes that it will cost 382 to do a sequential scan, versus
490 for an indexed scan. Hence why it prefers to do the sequential scan.
Try running explain analyze to see if how accurate it is.

As Janning mentioned, sometimes sequential scans *are* faster. If the
number of entries that will be found is large compared to the number of
total entries (I don't know the percentages, but probably >30-40%), then
it is faster to just load the data and scan through it, rather than
doing a whole bunch of indexed lookups.

John
=:->

Attachment

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: TestPerf Project started
Next
From: Rod Taylor
Date:
Subject: Re: IBM P-series machines (was: Excessive context