To: pgsql-performance@postgresql.org
From: =?ISO-8859-1?Q?Nis_J=F8rgensen?= <nis@superlativ.dk>
Subject: Re: Seqscan
Date: Tue, 23 Oct 2007 15:36:21 +0200
Lines: 38
Message-ID: <ffktcs$sbk$1@ger.gmane.org>
References: <1193107511.26301.59.camel@jdavis>
	<766975.88585.qm@web50908.mail.re2.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
In-Reply-To: <766975.88585.qm@web50908.mail.re2.yahoo.com>

(Please don't top-post. )

Adrian Demaestri skrev:
> */Jeff Davis <pgsql@j-davis.com>/* escribió:
> 
>     On Mon, 2007-10-22 at 19:24 -0700, Adrian Demaestri wrote:
>     > Hi,
>     > I think planner should use other plans than seqscan to solve querys
>     > like select * from hugetable limit 1, especially when the talbe is
>     > very large. Is it solved in newer versions or is there some open
>     > issues about it?.
>     > thanks
>     > I'm working with postgres 8.0.1,
> 
>     For the query in question, what would be faster than a seqscan? It
>     doesn't read the whole table, it only reads until it satisfies the limit
>     clause.

> It is not actualy a table, sorry, it is a quite complex view that
> involve three large tables.


If hugetable isn't a table, you chose a really bad name for it.

What you have here is a specific query performing badly, not a generic
issue with all queries containing "LIMIT X". You might of course have
found a construct which the planner has problems with - but the first
step is to let us see the result of EXPLAIN ANALYZE.

Anyway, I think you might be hitting this issue:

"Fix mis-planning of queries with small LIMIT values due to poorly
thought out "fuzzy" cost comparison"
(http://www.postgresql.org/docs/8.0/static/release-8-0-4.html)

which was fixed in 8.0.4 . You should upgrade.

Nis