Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 33A866504F8
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 24 Nov 2008 15:13:18 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 00767-01-3
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 24 Nov 2008 15:13:14 -0400 (AST)
Received: from news.hub.org (news.hub.org [200.46.204.72])
	by mail.postgresql.org (Postfix) with ESMTP id 0DB44650594
	for <pgsql-performance@postgresql.org>;
	Mon, 24 Nov 2008 15:11:26 -0400 (AST)
Received: from news.hub.org (news.hub.org [200.46.204.72])
	by news.hub.org (8.14.1/8.14.1) with ESMTP id mAOJBNIS089774
	for <pgsql-performance@postgresql.org>;
	Mon, 24 Nov 2008 15:11:23 -0400 (AST)
	(envelope-from news@news.hub.org)
Received: (from news@localhost)
	by news.hub.org (8.14.1/8.14.1/Submit) id mAOIrAai070540
	for pgsql-performance@postgresql.org;
	Mon, 24 Nov 2008 14:53:10 -0400 (AST) (envelope-from news)
From: "Andrus" <kobruleht2@hot.ee>
X-Newsgroups: pgsql.performance
Subject: Re: limit clause produces wrong query plan
Date: Mon, 24 Nov 2008 19:26:22 +0200
Organization: Hub.Org Networking Services
Lines: 18
Message-ID: <gget6m$24rv$1@news.hub.org>
References: <ggciha$1v26$1@news.hub.org>
	<0e6967e0-fb33-49aa-a745-a1d11ef6a9e0@q9g2000yqc.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@news.hub.org
In-Reply-To: 
 <0e6967e0-fb33-49aa-a745-a1d11ef6a9e0@q9g2000yqc.googlegroups.com>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
To: pgsql-performance@postgresql.org
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5
	tests=STOX_REPLY_TYPE=0.001
X-Spam-Level: 
X-Archive-Number: 200811/237
X-Sequence-Number: 31968

> it was veery fast. To be honest I do not know what is happening?!

This is really weird.
It seems that PostgreSql OFFSET / LIMIT are not optimized and thus typical 
paging queries

SELECT ... FROM bigtable ORDER BY intprimarykey OFFSET pageno*100 LIMIT 100

or even first page query

SELECT ... FROM bigtable ORDER BY intprimarykey OFFSET 0 LIMIT 100

cannot be used in PostgreSql at all for big tables.

Do you have any idea how to fix this ?

Andrus.