Re: Indexscan is only used if we use "limit n" - Mailing list pgsql-performance

From Mark Lewis
Subject Re: Indexscan is only used if we use "limit n"
Date
Msg-id 1187208190.23831.55.camel@archimedes
Whole thread Raw
In response to Indexscan is only used if we use "limit n"  (Sebastián Baioni <sebaioni-postgresql@yahoo.com.ar>)
List pgsql-performance
On Wed, 2007-08-15 at 16:36 -0300, Sebastián Baioni wrote:
> Hello,
> Whe are running PostgreSQL 8.2.0 on amd64-portbld-freebsd6.2, compiled
> by GCC cc (GCC) 3.4.6 [FreeBSD] 20060305.
> The query only uses the index if we have a "limit n":
>
> Without "Limit n"
> explain
> select esapcuit, esapcuil
> from esact00 t1
> order by esapcuit, esapcuil
>
> Sort  (cost=843833.82..853396.76 rows=3825177 width=30)
>   Sort Key: esapcuit, esapcuil
>   ->  Seq Scan on esact00 t1  (cost=0.00..111813.77 rows=3825177
> width=30)
>
> With "Limit n"
> explain
> select esapcuit, esapcuil
> from esact00 t1
> order by esapcuit, esapcuil
> limit 1

This isn't really unexpected-- it's faster to do a full sequential scan
of a table than it is to do a full index traversal over the table.  And
usually it's still cheaper even after sorting the results of the full
table scan.

So as near as we can tell, PG is just doing what it's supposed to do and
picking the best plan it can.

You didn't really ask a question-- is this causing problems somehow, or
were you just confused by the behavior?

-- Mark

pgsql-performance by date:

Previous
From: joao
Date:
Subject: Re: Indexscan is only used if we use "limit n"
Next
From: Philipp Specht
Date:
Subject: Re: Stable function optimisation