Re: Indexscan is only used if we use "limit n"

From: Mark Lewis <mark(dot)lewis(at)mir3(dot)com>
To: sebaioni-postgresql(at)yahoo(dot)com(dot)ar
Cc: Performance PostgreSQL <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Indexscan is only used if we use "limit n"
Date: 2007-08-15 20:03:10
Message-ID: 1187208190.23831.55.camel@archimedes
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Philipp Specht 2007-08-15 20:48:34 Re: Stable function optimisation
Previous Message joao 2007-08-15 20:02:43 Re: Indexscan is only used if we use "limit n"