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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
