X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id C616F9DCAEE for ; Tue, 6 Dec 2005 07:36:53 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 89569-10 for ; Tue, 6 Dec 2005 07:36:55 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from service-web.de (p15093784.pureserver.info [217.160.106.224]) by postgresql.org (Postfix) with ESMTP id 2D6B89DD5F7 for ; Tue, 6 Dec 2005 07:36:51 -0400 (AST) Received: from [10.100.1.50] (074-016-066-080.eggenet.de [80.66.16.74]) by service-web.de (Postfix) with ESMTP id 90694200034; Tue, 6 Dec 2005 12:36:53 +0100 (CET) Message-ID: <439577D2.9090208@wildenhain.de> Date: Tue, 06 Dec 2005 12:36:50 +0100 From: Tino Wildenhain User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050929) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Joost Kraaijeveld Cc: Csaba Nagy , Pgsql-Performance Subject: Re: Can this query go faster??? References: <1133862229.8837.61.camel@Panoramix> <1133862777.4779.185.camel@coppola.muc.ecircle.de> <1133864460.8837.69.camel@Panoramix> <439568C4.8050601@wildenhain.de> <1133868084.8837.73.camel@Panoramix> In-Reply-To: <1133868084.8837.73.camel@Panoramix> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200512/159 X-Sequence-Number: 15980 Joost Kraaijeveld schrieb: > Hi Tino, > .. > >>Cursor would work too but you would need to have a persistent connection. > > I just tried it: a cursor is not faster (what does not surprise me at > all, as the amount of work looks the same to me) Actually no, if you scroll forward, you just ask the database for the next rows to materialize. So if you are ahead in your database and ask for next rows, it should be faster then working w/ an offset from start each time.