Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W7nlj-0006zS-JZ for pgsql-performance@arkaria.postgresql.org; Mon, 27 Jan 2014 15:06:35 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1W7nli-0006Mm-Vy for pgsql-performance@arkaria.postgresql.org; Mon, 27 Jan 2014 15:06:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W7nlh-0006LY-J1 for pgsql-performance@postgresql.org; Mon, 27 Jan 2014 15:06:33 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W7nlb-0005Ya-8s for pgsql-performance@postgresql.org; Mon, 27 Jan 2014 15:06:33 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s0RF6O32002632; Mon, 27 Jan 2014 10:06:24 -0500 From: Tom Lane To: Stelian Iancu cc: pgsql-performance@postgresql.org Subject: Re: Slow query (wrong index used maybe) In-reply-to: <1390833860.7369.75825537.0CAF7BA8@webmail.messagingengine.com> References: <1390833860.7369.75825537.0CAF7BA8@webmail.messagingengine.com> Comments: In-reply-to Stelian Iancu message dated "Mon, 27 Jan 2014 06:44:20 -0800" Date: Mon, 27 Jan 2014 10:06:24 -0500 Message-ID: <2631.1390835184@sss.pgh.pa.us> X-Pg-Spam-Score: -2.4 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Stelian Iancu writes: > I have Postrgres 9.3 running on a Linux machine with 32GB RAM. I have a > fairly large database (some tables with approx. 1 mil. records) and I > have the following query: > [ 13-way join joined to a 3-way join ] Think you'll need to raise join_collapse_limit and from_collapse_limit to get the best plan here. The planning time might hurt, though. TBH that schema looks designed for inefficiency; you'd be better off rethinking the design rather than hoping the planner is smart enough to save you from it. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance