Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUMQW-0001nT-Gm for pgsql-performance@arkaria.postgresql.org; Mon, 01 Aug 2016 23:15:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bUMQV-0008Fz-UT for pgsql-performance@arkaria.postgresql.org; Mon, 01 Aug 2016 23:15:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bUMQU-0008F6-5f for pgsql-performance@postgresql.org; Mon, 01 Aug 2016 23:15:14 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bUMQN-00040B-3L for pgsql-performance@postgresql.org; Mon, 01 Aug 2016 23:15:13 +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 u71NF5V8021014; Mon, 1 Aug 2016 19:15:05 -0400 From: Tom Lane To: Andreas Joseph Krogh cc: pgsql-performance@postgresql.org Subject: Re: Very poor performance with Nested Loop Anti Join In-reply-to: References: Comments: In-reply-to Andreas Joseph Krogh message dated "Mon, 01 Aug 2016 15:33:04 +0200" Date: Mon, 01 Aug 2016 19:15:05 -0400 Message-ID: <21013.1470093305@sss.pgh.pa.us> X-Pg-Spam-Score: -3.1 (---) 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 Andreas Joseph Krogh writes: > This query performs terribly slow (~26 minutes, 1561346.597ms): Seems like the key misestimation is on the inner antijoin: > -> Hash Anti Join (cost=654.21..4008.72 rows=1 width=8) (actual time=9.016..40.672 rows=76174 loops=1) > Hash Cond: (il.invoice_id = creditnote.credit_against) > -> Seq Scan on onp_crm_invoice_line il (cost=0.00..3062.01 rows=78001 width=8) (actual time=0.005..11.259 rows=78614 loops=1) > -> Hash (cost=510.56..510.56 rows=11492 width=8) (actual time=8.940..8.940 rows=372 loops=1) > Buckets: 16384 Batches: 1 Memory Usage: 143kB > -> Seq Scan on onp_crm_invoice creditnote (cost=0.00..510.56 rows=11492 width=8) (actual time=0.014..7.882 rows=11507 loops=1) > Filter: ((sent_date <= '2016-06-27'::date) AND ((status_key)::text = 'INVOICE_STATUS_INVOICED'::text)) > Rows Removed by Filter: 149 If it realized that this produces 78k rows not 1, it'd likely do something smarter at the outer antijoin. I have no idea why that estimate's so far off though. What PG version is this? Stats all up to date on these two tables? Are the rows excluded by the filter condition on "creditnote" significantly different from the rest of that table? 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