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 2A5969DCAC3 for ; Tue, 6 Dec 2005 08:42:44 -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 03187-04 for ; Tue, 6 Dec 2005 08:42:47 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail3.ecircle.de (unknown [195.140.186.206]) by postgresql.org (Postfix) with ESMTP id F14FE9DCAEE for ; Tue, 6 Dec 2005 08:42:41 -0400 (AST) Received: from deimos.muc.ecircle.de (deimos.muc.ecircle.de [192.168.1.4]) by mail3.ecircle.de (READY) with ESMTP id 48B8011C031; Tue, 6 Dec 2005 13:42:45 +0100 (CET) Received: from [192.168.1.110] ([192.168.1.110]) by deimos.muc.ecircle.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Dec 2005 13:32:57 +0100 Subject: Re: Can this query go faster??? From: Csaba Nagy To: Joost Kraaijeveld Cc: Tino Wildenhain , Pgsql-Performance In-Reply-To: <1133871645.8837.78.camel@Panoramix> 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> Content-Type: text/plain Message-Id: <1133872377.4779.200.camel@coppola.muc.ecircle.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 06 Dec 2005 13:32:57 +0100 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2005 12:32:57.0567 (UTC) FILETIME=[301966F0:01C5FA61] 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/164 X-Sequence-Number: 15985 On Tue, 2005-12-06 at 13:20, Joost Kraaijeveld wrote: [snip] > 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. In this case the query will very likely not work faster. It must always visit all the records till the required offset. If the plan should be faster using the index, then you probably need to analyze (I don't recall from your former posts if you did it recently or not), in any case you could check an "explain analyze" to see if the planner is mistaken or not - you might already know this. Cheers, Csaba.