On Wed, Dec 3, 2014 at 2:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Dec 3, 2014 at 12:08 PM, Tom Lane <tgl@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.