Subject: Re: Indexscan is only used if we use "limit n"
From: Mark Lewis <mark.lewis@mir3.com>
To: sebaioni-postgresql@yahoo.com.ar
Cc: Performance PostgreSQL <pgsql-performance@postgresql.org>
In-Reply-To: <377451.48008.qm@web36104.mail.mud.yahoo.com>
References: <377451.48008.qm@web36104.mail.mud.yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Organization: MIR3, Inc.
Date: Wed, 15 Aug 2007 13:03:10 -0700
Message-Id: <1187208190.23831.55.camel@archimedes>
Mime-Version: 1.0

On Wed, 2007-08-15 at 16:36 -0300, Sebasti=C3=A1n 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":
>=20
> Without "Limit n"
> explain
> select esapcuit, esapcuil
> from esact00 t1
> order by esapcuit, esapcuil
>=20
> Sort  (cost=3D843833.82..853396.76 rows=3D3825177 width=3D30)
>   Sort Key: esapcuit, esapcuil
>   ->  Seq Scan on esact00 t1  (cost=3D0.00..111813.77 rows=3D3825177
> width=3D30)
>=20
> 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