Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 0D7882E008E for ; Tue, 6 May 2008 15:24:46 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 46813-04-2 for ; Tue, 6 May 2008 15:24:36 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by developer.postgresql.org (Postfix) with ESMTP id A50DC2E0094 for ; Tue, 6 May 2008 15:24:33 -0300 (ADT) Received: from gwsout01.mbox.net (gwsout01.mbox.net [165.212.64.24]) by gateout02.mbox.net (Postfix) with ESMTP id A767D721431; Tue, 6 May 2008 18:24:31 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gwsout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID034meFsyf3650Xo1; Tue, 06 May 2008 18:24:31 -0000 X-USANET-Source: 165.212.116.254 IN sthomas@leapfrogonline.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID034meFsyf3650Xo1 Received: from s1hub2.EXCHPROD.USA.NET ([10.120.220.32]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 12:24:31 -0600 Received: from [192.168.50.198] (70.230.73.42) by exchange.postoffice.net (10.120.220.32) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 6 May 2008 19:24:31 +0100 Subject: Re: multiple joins + Order by + LIMIT query performance issue From: Shaun Thomas To: Antoine Baudoux CC: "pgsql-performance@postgresql.org" In-Reply-To: References: <938EC908-FB9A-4BFA-950A-053BE3C87085@taktik.be> <1210092220.14833.33.camel@berners-lee> Content-Type: text/plain Organization: Leapfrog Online Date: Tue, 6 May 2008 13:24:33 -0500 Message-ID: <1210098273.14833.55.camel@berners-lee> MIME-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2008 18:24:31.0454 (UTC) FILETIME=[6D609FE0:01C8AFA6] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.615 tagged_above=0 required=5 tests=AWL=-0.817, DNS_FROM_OPENWHOIS=2.431, WHOIS_NETSOLPR=0.001 X-Spam-Level: * X-Archive-Number: 200805/103 X-Sequence-Number: 30071 On Tue, 2008-05-06 at 18:24 +0100, Antoine Baudoux wrote: > Isnt the planner fooled by the index on the sorting column? > If I remove the index the query runs OK. In your case, for whatever reason, the stats say doing the index scan on the sorted column will give you the results faster. That isn't always the case, and sometimes you can give the same query different where clauses and that same slow-index-scan will randomly be fast. It's all based on the index distribution and the particular values being fetched. This goes back to what Tom said. If you know a "miss" can result in terrible performance, it's best to just recode the query to avoid the situation. > This is crazy, so simply by adding a LIMIT to a query, the planning is > changed in a very bad way. Does the planner use the LIMIT as a sort of > hint? Yes. That's actually what tells it the index scan can be a "big win." If it scans the index backwards on values returned from some of your joins, it may just have to find 25 rows and then it can immediately stop scanning and just give you the results. In normal cases, this is a massive performance boost when you have an order clause and are expecting a ton of results, (say you're getting the first 25 rows of 10000 or something). But if it would be faster to generate the results and *then* sort, but Postgres thinks otherwise, you're pretty much screwed. But that's the long answer. You have like 3 ways to get around this now, so pick one. ;) -- Shaun Thomas Database Administrator Leapfrog Online 807 Greenwood Street Evanston, IL 60201 Tel. 847-440-8253 Fax. 847-570-5750 www.leapfrogonline.com