From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jay Levitt <jay(dot)levitt(at)gmail(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Subquery in a JOIN not getting restricted? |
Date: | 2011-11-10 15:22:48 |
Message-ID: | 8071.1320938568@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jay Levitt <jay(dot)levitt(at)gmail(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jay Levitt | 2011-11-10 15:42:53 | Re: Subquery in a JOIN not getting restricted? |
Previous Message | Craig Ringer | 2011-11-10 14:28:10 | Re: IMMUTABLE STABLE functions, daily updates |