Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XgcaT-0001Fq-9H for pgsql-performance@arkaria.postgresql.org; Tue, 21 Oct 2014 16:47:09 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XgcaS-00063w-KL for pgsql-performance@arkaria.postgresql.org; Tue, 21 Oct 2014 16:47:08 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XgcaR-00063o-8O for pgsql-performance@postgresql.org; Tue, 21 Oct 2014 16:47:07 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XgcaN-0004BA-Iu for pgsql-performance@postgresql.org; Tue, 21 Oct 2014 16:47:05 +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 s9LGkk3q006039; Tue, 21 Oct 2014 12:46:46 -0400 From: Tom Lane To: Andrew Dunstan cc: Marco Di Cesare , Merlin Moncure , "pgsql-performance@postgresql.org" Subject: Re: Query with large number of joins In-reply-to: <54468A4A.8090908@dunslane.net> References: <0a72826fe7d04b71b9ab47d24992d898@CO2PR0701MB759.namprd07.prod.outlook.com> <54468A4A.8090908@dunslane.net> Comments: In-reply-to Andrew Dunstan message dated "Tue, 21 Oct 2014 12:31:06 -0400" Date: Tue, 21 Oct 2014 12:46:46 -0400 Message-ID: <6038.1413910006@sss.pgh.pa.us> X-Pg-Spam-Score: -3.3 (---) 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 Andrew Dunstan writes: > Have you tried a) either turning off geqo or setting geqo_threshold > fairly high b) setting join_collapse_limit fairly high (assuming all the > above join targets are tables and not views, setting it to something > like 25 should do the trick. You'd have to do both, I think, to get an exhaustive plan search. In any case, this query is going to result in full table scans of most of the tables, because there just aren't very many WHERE constraints; so expecting it to run instantaneously is a pipe dream. I'm not sure that there's a significantly better plan to be had. 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