Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T1t9a-0001RE-1g for pgsql-performance@postgresql.org; Thu, 16 Aug 2012 06:01:58 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T1t9Y-0001PS-1S for pgsql-performance@postgresql.org; Thu, 16 Aug 2012 06:01:57 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q7G61puO002704; Thu, 16 Aug 2012 02:01:51 -0400 (EDT) From: Tom Lane To: Josh Berkus cc: pgsql-performance@postgresql.org Subject: Re: 7k records into Sort node, 4.5m out? In-reply-to: <502C3DE2.9060703@agliodbs.com> References: <32B51AEA-E940-40CF-BA54-C7D4E3E1F0D7@thebuild.com> <10304.1344910305@sss.pgh.pa.us> <623F2FF3-B79D-419A-929A-41C707DD5EA3@thebuild.com> <16268.1345063872@sss.pgh.pa.us> <502C0E6B.1040402@agliodbs.com> <20520.1345067076@sss.pgh.pa.us> <502C3DE2.9060703@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Wed, 15 Aug 2012 17:25:06 -0700" Date: Thu, 16 Aug 2012 02:01:51 -0400 Message-ID: <2703.1345096911@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201208/100 X-Sequence-Number: 47638 Josh Berkus writes: > SELECT COUNT(*) > FROM "user" > INNER JOIN "house" > ON ("user"."house_id" = "house"."id") > LEFT OUTER JOIN "district" > ON ("house"."district_id" = "district"."id") > WHERE ("user"."status" = 0 > AND ("district"."update_status" = 2 > OR "district"."update_status" = 3 ) > AND ("user"."valid" = 1 > OR "user"."valid" = 3 ) > AND "district"."is_test" = false ); > However, since the anonymization above doesn't quite match that used in > the EXPLAIN plan, I'm not sure what you'll get out of it. And yes, we > know that the outer join is being invalidated. Ah, I see where I was confused: in the original query plan I'd been imagining that charlie.sierra was a unique column, but your gloss on that as being house.district_id implies that it's highly non-unique. And looking at the rowcounts in the original plan backs that up: there are about 600 house rows per district row. So my thought of having district as the outer side of a nestloop scanning the index on house.district_id would not really work very well --- maybe it would end up cheaper than the mergejoin plan, but it's far from a clear-cut win. On the whole I'm thinking the code is operating as designed here. regards, tom lane