Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bpNMZ-0001NV-AX for pgsql-admin@arkaria.postgresql.org; Wed, 28 Sep 2016 22:30:03 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bpNMY-0006fV-Ta for pgsql-admin@arkaria.postgresql.org; Wed, 28 Sep 2016 22:30:02 +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 1bpNKr-0003en-Is for pgsql-admin@postgresql.org; Wed, 28 Sep 2016 22:28:17 +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.84_2) (envelope-from ) id 1bpNKl-0004Aq-3M for pgsql-admin@postgresql.org; Wed, 28 Sep 2016 22:28:16 +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 u8SMS97s031746; Wed, 28 Sep 2016 18:28:09 -0400 From: Tom Lane To: Jorge Torralba cc: "pgsql-admin@postgresql.org" Subject: Re: Query Plan difference between 9.3 and 9.5 for the worse. Help !!! In-reply-to: References: Comments: In-reply-to Jorge Torralba message dated "Wed, 28 Sep 2016 10:53:32 -0700" Date: Wed, 28 Sep 2016 18:28:09 -0400 Message-ID: <31745.1475101689@sss.pgh.pa.us> X-Pg-Spam-Score: -4.9 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Jorge Torralba writes: > We have been struggling with a query on our system that under 9.3 was > taking 15ms or so to run and after upgrading to 9.5 it is taking over > 2500ms. > You can see the explains are very different but I cannot figure out why > when using the same data on both system. Hard to comment on this when you haven't shown us the query nor the table schemas. But I'm going to guess based on the lack of a Limit node in the second plan that your query involves WHERE EXISTS(SELECT ... LIMIT 1). The LIMIT 1 would have defeated optimization till recently, but now the planner knows that it's a no-op in this context and throws it away, and then is able to convert the sub-select to a semijoin. Usually that results in a better plan; there's far from enough info here to guess why it's worse for you. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin