Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f6eBH-0007gr-OB for pgsql-performance@arkaria.postgresql.org; Thu, 12 Apr 2018 15:30:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f6eBG-0005do-Ax for pgsql-performance@arkaria.postgresql.org; Thu, 12 Apr 2018 15:30:34 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f6eBG-0005de-0X for pgsql-performance@lists.postgresql.org; Thu, 12 Apr 2018 15:30:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f6eBD-0002wY-4T for pgsql-performance@lists.postgresql.org; Thu, 12 Apr 2018 15:30:32 +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 w3CFUSx8012797; Thu, 12 Apr 2018 11:30:28 -0400 From: Tom Lane To: =?UTF-8?Q?Eduard_Catal=C3=A0?= cc: pgsql-performance@lists.postgresql.org Subject: Re: Table order at FROM clause affects performance? In-reply-to: References: Comments: In-reply-to =?UTF-8?Q?Eduard_Catal=C3=A0?= message dated "Thu, 12 Apr 2018 16:35:09 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12795.1523547028.1@sss.pgh.pa.us> Date: Thu, 12 Apr 2018 11:30:28 -0400 Message-ID: <12796.1523547028@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk =?UTF-8?Q?Eduard_Catal=C3=A0?= writes: > Given this statement: > SELECT *several_fields* FROM A, B, C WHERE *conditions* > A, B are tables with several LEFT JOINS but they act as one subquery. You really can't expect useful help if you are going to pose questions that abstract. You have removed details that count, and made assumptions that don't necessarily hold (e.g., what does "act as one subquery" mean?) Probably the most likely bet, on this limited information, is that there are enough base tables hidden inside your query that you're running into join_collapse_limit and/or from_collapse_limit, resulting in the planner failing to investigate the best available plan in one case. Raising those limits would help, if so. But it could easily be something else. There's some suggestions here about how to ask useful questions: https://wiki.postgresql.org/wiki/Slow_Query_Questions regards, tom lane