On Wed, Dec 3, 2014 at 2:09 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Dec 3, 2014 at 12:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I would envision the planner starting out generating the first subplan >> (without the optimization), but as it goes along, noting whether there >> are any opportunities for join removal. At the end, if it found that >> there were such opportunities, re-plan assuming that removal is possible. >> Then stick a switch node on top. >> >> This would give optimal plans for both cases, and it would avoid the need >> for lots of extra planner cycles when the optimization can't be applied >> ... except for one small detail, which is that the planner has a bad habit >> of scribbling on its own input. I'm not sure how much cleanup work would >> be needed before that "re-plan" operation could happen as easily as is >> suggested above. But in principle this could be made to work. > > Doesn't this double the planning overhead, in most cases for no > benefit? The alternative plan used only when there are deferred > triggers is rarely going to get used.
It shouldn't. It will only double (at worst) planning overhead for the queries that do have removable joins, which would be the ones benefiting from the extra work. Whether that extra work pays off is the question to ask here. Perhaps whether or not to remove the joins could be a decision made accounting for overall plan cost and fraction of joins removed, as to avoid the extra planning if execution will be fast anyway. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
