Added in basic support for broadcast nested loop join

[revans2]

I would appreciate some reviews on this.

It is a part of #265 but is missing CartesianExec which is an implementation that shows up if one of the tables is too larger to be broadcast and it is an inner or cross join with no equality comparison.

It adds in support for Cross equality joins, that in those cases are the same as an Inner join.

It also add in support for BroadcastNestedLoopJoin on Cross and Inner joins. The biggest issue is the amount of memory that could be used by a Cross join this big.

I plan on trying to use the current memory size of each table (left and right) to decide if we should play some games with memory. If the size is too large then we break the tables down into smaller pieces.

i.e.

left_size_per_row = left_size_memory/left_rows
right_size_per_row = right_size_memory/right_rows

if (((left_size_per_row + right_size_per_row) * left_rows * right_rows) > target_batch_size) {
  split the tables.  Preferable just split the stream table, but if we cannot, then split both and loop.
}

This would still not fix all cases, because we could broadcast something really large and blow up from just trying to hold it in memory.

[revans2]

build

[jlowe]

Took a quick glance, seems fine to me. As you noted, would be great to explore sharing a lot of the boilerplate build type handling, output distribution, etc. that is common with the existing hash join.

[revans2]

build

[revans2]

I updated the code so BroadcastnestedLoopJoin is off by default. I could not find a clean way to reuse anything between it and the other join implementations. It would take about as much code to make it common as it saved, so I have left them separate. We might revisit it again in the future if someone has a better idea on how to do it (I tried a trait to mix in).

I also filed a follow on issue #302 to try and fix some of the memory issues and let us turn this on by default.