Fix exploding Delim Joins

[Tmonster]

After refactoring the join order optimizer, delim scans were allowed to be reordered. Unfortunately, getting statistics from delim scans wasn't possible and the cardinality was estimated to be 0. This throws off the join order optimizer. Delim scans become perfect candidates for first joins because the cardinality of any join with a (supposedly empty) table is 0, which is great for the cost model.

In some cases, this delim scan has a lot of data, and the join at the bottom of the table can blow up significantly. A proper fix for this would be to inspect the delim join and get the query from there, but to match 0.8.1 functionality, the idea is to not allow delim scans to be reordered.

Added a benchmark for testing. On my laptop 8 cores, 16GB memory, results look like this

current

benchmark/micro/join/delim_join_no_blowup.benchmark 1   14.247793
benchmark/micro/join/delim_join_no_blowup.benchmark 2   13.947187
benchmark/micro/join/delim_join_no_blowup.benchmark 3   13.267580
benchmark/micro/join/delim_join_no_blowup.benchmark 4   13.384650
benchmark/micro/join/delim_join_no_blowup.benchmark 5   13.450060

with fix

benchmark/micro/join/delim_join_no_blowup.benchmark 1   1.472236
benchmark/micro/join/delim_join_no_blowup.benchmark 2   1.508781
benchmark/micro/join/delim_join_no_blowup.benchmark 3   1.618396
benchmark/micro/join/delim_join_no_blowup.benchmark 4   1.430282
benchmark/micro/join/delim_join_no_blowup.benchmark 5   1.412266

[lnkuiper]

Looks good to me!

[Mytherin]

Thanks! LGTM. For the future we should be able to use the cardinality estimate obtained in the original delim join and propagate that estimate to each of the delim scans.