Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T1kjW-00089c-4m for pgsql-performance@postgresql.org; Wed, 15 Aug 2012 21:02:30 +0000 Received: from smtp.01.com ([199.36.142.181]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T1kjU-00027N-MM for pgsql-performance@postgresql.org; Wed, 15 Aug 2012 21:02:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0C6CC3F61A8 for ; Wed, 15 Aug 2012 16:02:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmrKIWi7QfEu for ; Wed, 15 Aug 2012 16:02:26 -0500 (CDT) Received: from smtp.01.com (localhost.localdomain [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D738D3F67A9 for ; Wed, 15 Aug 2012 16:02:26 -0500 (CDT) Received: from Sidney-Stratton.local (70-36-143-92.dsl.dynamic.sonic.net [70.36.143.92]) by smtp-out-1.01.com (Postfix) with ESMTPSA id A45F43F61A8 for ; Wed, 15 Aug 2012 16:02:26 -0500 (CDT) Message-ID: <502C0E6B.1040402@agliodbs.com> Date: Wed, 15 Aug 2012 14:02:35 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: 7k records into Sort node, 4.5m out? References: <32B51AEA-E940-40CF-BA54-C7D4E3E1F0D7@thebuild.com> <10304.1344910305@sss.pgh.pa.us> <623F2FF3-B79D-419A-929A-41C707DD5EA3@thebuild.com> <16268.1345063872@sss.pgh.pa.us> In-Reply-To: <16268.1345063872@sss.pgh.pa.us> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201208/87 X-Sequence-Number: 47625 On 8/15/12 1:51 PM, Tom Lane wrote: > Christophe Pettus writes: >> On Aug 13, 2012, at 7:11 PM, Tom Lane wrote: >>> The whole thing looks a bit weird to me --- why did it not use a >>> nestloop join with inner indexscan on charlie? With 7000 rows on the >>> other side, the estimated cost for that shouldn't have been more than >>> about 30000 ... > >> Here's the same query with set enable_megejoin = off. All of the other query tuning parameters are default. > >> http://explain.depesz.com/s/dqO > > Maybe you had better show us the actual query, and the table/index > definitions. Because it's sure making odd choices here. This seems > like the wrong join order altogether ... We'll need to do that off-list for confidentiality reasons. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com