On Sun, Jul 19, 2009 at 10:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Yeah. Ideally this sort of thing would happen in prepjointree.c, but > we don't have nearly enough information at that stage.
Tom, You've mentioned this point a couple of times - what is ideal about prepjointree? Reading through the "optimizer functions" section of src/backend/optimizer/README, it seems like the earliest point at which we could do this would be just before the call to make_one_rel(). I think that would eliminate some redundant computation. Right now, if we have A LJ B LJ C we'll try joining A to C and discover that it's removable; later we'll try joining {A B} to C and again discover that C is removable. But maybe it could be attacked from the other direction: look at C and try to figure out whether there's a some baserel or joinrel to which we can join it removably. If we find one, we don't need to bother generating seq scan or index paths for C, reloptinfos for joinrels that include C, etc. The problem with moving it back any further seems to be that we have to know which clauses are mergejoinable before we can do the necessary computations; I think flattening of the query tree has to already be done too. Obviously this is all 9.1 material but PG east has me thinking about this topic again... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers