Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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