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 1efwlF-00025S-IZ for pgsql-performance@arkaria.postgresql.org; Sun, 28 Jan 2018 23:53:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efwlE-0004K9-7B for pgsql-performance@arkaria.postgresql.org; Sun, 28 Jan 2018 23:53:20 +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.84_2) (envelope-from ) id 1efwlD-0004Jy-TF for pgsql-performance@lists.postgresql.org; Sun, 28 Jan 2018 23:53:20 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1efwl6-0006EF-LX for pgsql-performance@postgresql.org; Sun, 28 Jan 2018 23:53:18 +0000 Received: from bruce by momjian.us with local (Exim 4.84_2) (envelope-from ) id 1efwl4-00069C-56; Sun, 28 Jan 2018 18:53:10 -0500 Date: Sun, 28 Jan 2018 18:53:10 -0500 From: Bruce Momjian To: Justin Pryzby Cc: johannes =?iso-8859-1?Q?gra=EBn?= , Pavel Stehule , "pgsql-performance@postgresql.org" Subject: Re: [PERFORM] performance drop after upgrade (9.6 > 10) Message-ID: <20180128235310.GA5024@momjian.us> References: <20171026194515.GV21735@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171026194515.GV21735@telsasoft.com> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Oct 26, 2017 at 02:45:15PM -0500, Justin Pryzby wrote: > On Tue, Oct 24, 2017 at 04:15:59PM +0200, johannes graën wrote: > > Hi Pavel, *, > > > > you were right with ANALYZing the DB first. However, even after doing > > so, I frequently see Seq Scans where an index was used before. This > > usually cooccurs with parallelization and looked different before > > upgrading to 10. I can provide an example for 10 [1], but I cannot > > generate a query plan for 9.6 anymore. > > > > Any ideas what makes the new version more seqscanny? > > Is it because max_parallel_workers_per_gather now defaults to 2 ? > > BTW, I would tentatively expect a change in default to be documented in the > release notes but can't see that it's. > 77cd477c4ba885cfa1ba67beaa82e06f2e182b85 Oops, you are correct. The PG 10 release notes, which I wrote, should have mentioned this. :-( https://www.postgresql.org/docs/10/static/release-10.html -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +