Re: why my query is not using index??

From: John Meinel <john(at)johnmeinel(dot)com>
To: Francisco Reyes <lists(at)natserv(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: why my query is not using index??
Date: 2004-10-12 00:12:45
Message-ID: 416B217D.9090000@johnmeinel.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
=:->

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-10-12 00:28:28 Re: EXPLAIN ANALYZE much slower than running query normally
Previous Message Josh Berkus 2004-10-11 23:52:14 TestPerf Project started