> 1. I don't think that I'm currently handling removing eclass members > properly. So far the code just removes the Vars that belong to the relation > being removed. I likely should also be doing bms_del_member(ec->ec_relids, > relid); on the eclass, but perhaps I should just be marking the whole class > as "ec_broken = true" and adding another eclass all everything that the > broken one has minus the parts from the removed relation?
I haven't read the patch, but I think the question is why this needs to be different than what we do for left join removal.
I discovered over here -> http://www.postgresql.org/message-id/CAApHDvo5wCRk7uHBuMHJaDpbW-b_oGKQOuisCZzHC25=H3__fA@mail.gmail.com during the early days of the semi and anti join removal code that the planner was trying to generate paths to the dead rel. I managed to track the problem down to eclass members still existing for the dead rel. I guess we must not have eclass members for outer rels? or we'd likely have seen some troubles with left join removals already.
In the meantime I'll fix up the inner join removal code to properly delete the ec_relids member for the dead rel. I guess probably the restrict info should come out too.
I know it's late in the commitfest, but since there was next to no interest in semi and anti join removals, can I rename the patch in the commitfest app to be "Inner join removals"? It's either that or I'd mark that patch as rejected and submit this one in October.
