Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 0A4BEED2330 for ; Thu, 10 Nov 2011 11:23:01 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 25888-01-10 for ; Thu, 10 Nov 2011 15:22:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 50000ED232F for ; Thu, 10 Nov 2011 11:22:50 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id pAAFMnwv008072; Thu, 10 Nov 2011 10:22:49 -0500 (EST) To: Jay Levitt cc: Kevin Grittner , Merlin Moncure , pgsql-performance@postgresql.org Subject: Re: Subquery in a JOIN not getting restricted? In-reply-to: <4EBBD717.80507@gmail.com> References: <4EB84CB4.2010102@gmail.com> <4EB7FEFD0200002500042B1C@gw.wicourts.gov> <4EB80CAA0200002500042B3B@gw.wicourts.gov> <4EB86784.7080209@gmail.com> <4EB88C5A.2020704@gmail.com> <4EBA44B70200002500042BC8@gw.wicourts.gov> <4EBA8C100200002500042C23@gw.wicourts.gov> <4EBBD717.80507@gmail.com> Comments: In-reply-to Jay Levitt message dated "Thu, 10 Nov 2011 08:52:23 -0500" Date: Thu, 10 Nov 2011 10:22:48 -0500 Message-ID: <8071.1320938568@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-3.101 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-1.201 X-Spam-Level: X-Archive-Number: 201111/132 X-Sequence-Number: 45643 Jay Levitt writes: > If the query was more like > select questions.id > from questions > join ( > select sum(u.id) > from users as u > group by u.id > ) as s > on s.id = questions.user_id > where questions.id = 1; > would you no longer be surprised that it scanned all user rows? Don't hold your breath waiting for that to change. To do what you're wishing for, we'd have to treat the GROUP BY subquery as if it were an inner indexscan, and push a join condition into it. That's not even possible today. It might be possible after I get done with the parameterized-path stuff I've been speculating about for a couple of years now; but I suspect that even if it is possible, we won't do it for subqueries because of the planner-performance hit we'd take from repeatedly replanning the same subquery. I'd suggest rephrasing the query to do the join underneath the GROUP BY. regards, tom lane