In our initial implementation of Indexed nested loop join, the IndexProbe stage only allowed for using an index on the inner side to satisfy a join predicate. We should consider generating plans which can use an index on the inner side to satisfy both a join predicate and single table predicates on the inner side.

This is a difficult problem given the current architecture of the join optimizer and its use of the classic plan enumerator. At the very least, it would require add a representation of bounds to IndexProbe node and invoking the single table plan enumerator in a way that allows us to extract the bounds for a particular index.

This will also have implications for the costing module as we will require the ability to compare the estimated costs for these newly enumerated plans.