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 772C29DD5F0 for ; Tue, 6 Dec 2005 08:30:28 -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 00688-08 for ; Tue, 6 Dec 2005 08:30:30 -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 9E2B09DD5EA for ; Tue, 6 Dec 2005 08:30:25 -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 22ADA200034; Tue, 6 Dec 2005 13:30:28 +0100 (CET) Message-ID: <43958461.2060106@wildenhain.de> Date: Tue, 06 Dec 2005 13:30:25 +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> <439577D2.9090208@wildenhain.de> <1133871645.8837.78.camel@Panoramix> In-Reply-To: <1133871645.8837.78.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/162 X-Sequence-Number: 15983 Joost Kraaijeveld schrieb: > On Tue, 2005-12-06 at 12:36 +0100, Tino Wildenhain wrote: > >>>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. > > Ah, a misunderstanding: I only need to calculate an index if the user > wants a record that is not in or adjacent to the cache (in which case I > can do a "select values > last value in the cache". So I must always > materialize all rows below the wanted index. > Yes, but still advancing a few blocks from where the cursor is should be faster then re-issuing the query and scroll thru the whole resultset to where you want to go.