On Sun, May 18, 2014 at 2:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <dgrowleyml@gmail.com> writes: > It looks like the existing join removals are done quite early in the > planning and redundant joins are removed before any subqueries from that > query are planned. So this innerrel->subroot->parse has not been done yet. > It seems to be done later in query_planner() when make_one_rel() is called.
It's true that we don't plan the subquery till later, but I don't see why that's important here. Everything you want to know is available from the subquery parsetree; so just look at the RTE, don't worry about how much of the RelOptInfo has been filled in.
Thanks. I think I've found what you're talking about in PlannerInfo simple_rte_array.
That's got the ball rolling.
> The best I can come up with on how to implement this is to have 2 stages of > join removals. Stage 1 would be the existing stage that attempts to remove > joins from non subqueries. Stage 2 would happen just after make_one_rel() > is called from query_planner(), this would be to attempt to remove any > subqueries that are not need, and if it managed to remove any it would > force a 2nd call to make_one_rel().
That sounds like a seriously bad idea. For one thing, it blows the opportunity to not plan the subquery in the first place. For another, most of these steps happen in a carefully chosen order because there are interdependencies. You can't just go back and re-run some earlier processing step. A large fraction of the complexity of analyzejoins.c right now arises from the fact that it has to undo some earlier processing; that would get enormously worse if you delayed it further.
Agreed, but at the time I didn't know that the subquery information was available elsewhere.
BTW, just taking one step back ... this seems like a pretty specialized requirement. Are you sure it wouldn't be easier to fix your app to not generate such silly queries?
Well, couldn't you say the same about any join removals? Of course the query could be rewritten to not reference that relation, but there are cases where removing the redundant join might be more silly, for example a fairly complex view may exist and many use cases for the view don't require all of the columns. It might be a bit of a pain to maintain a whole series of views with each required subset of columns instead of just maintaining a single view and allow callers to use what they need from it.
I came across the need for this at work this week where we have a grid in a UI where the users can select columns that they need to see in the grid. The data in each grid is supplied by a single view which contains all the possible columns that they might need, if the user is just using a narrow subset of those columns then it could seem quite wasteful to do more than is required.