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
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" |