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 1ezxx9-0000Mp-Qv for pgsql-performance@arkaria.postgresql.org; Sun, 25 Mar 2018 05:12:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ezxx8-0004D0-BE for pgsql-performance@arkaria.postgresql.org; Sun, 25 Mar 2018 05:12:22 +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 1ezxx8-0004Cr-0T for pgsql-performance@lists.postgresql.org; Sun, 25 Mar 2018 05:12:22 +0000 Received: from mx1.mailbox.org ([80.241.60.212]) by makus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ezxx0-0006li-Ky for pgsql-performance@lists.postgresql.org; Sun, 25 Mar 2018 05:12:20 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 0C62B42A14; Sun, 25 Mar 2018 07:12:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id XhQy5jxHJ-TP; Sun, 25 Mar 2018 07:12:10 +0200 (CEST) Message-ID: <1521954728.2350.24.camel@cybertec.at> Subject: Re: Should from_collapse be switched off? (queries 10 times faster) From: Laurenz Albe To: Peter , Tom Lane Cc: pgsql-performance@lists.postgresql.org Date: Sun, 25 Mar 2018 07:12:08 +0200 In-Reply-To: <20180323173658.GA58069@gate.oper.dinoex.org> References: <20180323100308.GA1188@gate.oper.dinoex.org> <1521805295.2471.40.camel@cybertec.at> <18405.1521814459@sss.pgh.pa.us> <20180323173658.GA58069@gate.oper.dinoex.org> Organization: Cybertec Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter wrote: > On Fri, Mar 23, 2018 at 10:14:19AM -0400, Tom Lane wrote: > > ! It's conceivable that the OP's problem is actually planning time > ! (if the query joins sufficiently many tables) and that restricting > ! the cost of the join plan search is really what he needs to do. > > Negative. Plnning time 10 to 27 ms. Execution time 600 to 6300 ms. > > ! Lacking any further information about the problem, we can't say. > ! We can, however, point to > ! https://wiki.postgresql.org/wiki/Slow_Query_Questions > ! concerning how to ask this type of question effectively. > > I strongly hope the data that I sent as followup will now > suffice Your expectations. Your reported execution times don't match the time reported in the EXPLAIN output... The cause of the long execution time is clear: The row count of the join between "places" (WHERE platz = 'WAEHR'), "wpnames" and "places AS places_1" is underestimated by a factor of 10 (1 row instead of 10). The nested loop join that is chosen as a consequence is now executed 10 times instead of the estimated 1 time, which is where almost all the execution time is spent. The question how to fix that is more complicated, and I cannot solve it off-hand with a complicated query like that. Setting "enable_nestloop = off" is as coarse as forcing "from_collapse = 1" and will negatively impact other queries - if it helps at all. You'll probably have to rewrite the query. Sorry that I cannot be of more help. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com