Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkytp-0005xE-KB for pgsql-performance@arkaria.postgresql.org; Thu, 15 May 2014 16:52:53 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wkytp-0001iW-2j for pgsql-performance@arkaria.postgresql.org; Thu, 15 May 2014 16:52:53 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkyto-0001iK-49 for pgsql-performance@postgresql.org; Thu, 15 May 2014 16:52:52 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkytl-0004Vv-Lj for pgsql-performance@postgresql.org; Thu, 15 May 2014 16:52:51 +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 s4FGqmJd028359; Thu, 15 May 2014 12:52:48 -0400 From: Tom Lane To: Scott Marlowe cc: "pgsql-performance@postgresql.org" Subject: Re: Query plan good in 8.4, bad in 9.2 and better in 9.3 In-reply-to: References: Comments: In-reply-to Scott Marlowe message dated "Thu, 15 May 2014 10:35:11 -0600" Date: Thu, 15 May 2014 12:52:48 -0400 Message-ID: <28358.1400172768@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) 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 Scott Marlowe writes: > OK so we have a query that does OK in 8.4, goes to absolute crap in > 9.2 and then works great in 9.3. Thing is we've spent several months > regression testing 9.2 and no time testing 9.3, so we can't just "go > to 9.3" in an afternoon. But we might have to. 9.2 seems hopelessly > broken here. > The query looks something like this: > SELECT COUNT(*) FROM u, ug > WHERE u.ugid = ug.id > AND NOT u.d > AND ug.somefield IN (SELECT somefunction(12345)); You really should show us somefunction's definition if you want useful comments. I gather however that it returns a set. 8.4 seems to be planning on the assumption that the set contains only one row, which is completely unjustified in general though it happens to be true in your example. 9.2 is assuming 1000 rows in the set, and getting a sucky plan because that's wrong. 9.3 is still assuming that; and I rather doubt that you are really testing 9.3 on the same data, because 9.2 is finding millions of rows in a seqscan of u while 9.3 is finding none in the exact same seqscan. I'd suggest affixing a ROWS estimate to somefunction, or better declaring it to return singleton not set if that's actually always the case. 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