Enable datafusion.optimizer.filter_null_join_keys by default

[Dandandan]

Which issue does this PR close?

Closes #12375

Rationale for this change

It is better to have it enabled by default, as pushing a filter down below a join is generally faster than the overhead saved by not having to execute the filter.
Besides that, in many cases the filter can be pushed down further to the scan or might enable other optimizations (now or future ones):

Benefits: Input to join is smaller, so smaller input, faster build, no nulls need to be hashed, lower chance for data skew, other join can be planned, downstream kernels are faster, can possibly be pushed down into scan, etc. In distributed setting, might save a lot of IO as well.

Downside: evaluation of expression + copying overhead if it doesn't filter out much rows. This might be slower than executing join without prefiltering on nulls.

What changes are included in this PR?

enable datafusion.optimizer.filter_null_join_keys, fix tests / expectations

Are these changes tested?

Existing tests

Are there any user-facing changes?

Only slightly different plans.

[Dandandan]

This was actually a regression in https://github.com/apache/datafusion/pull/

[alamb]

the link seems to be incomplete

[Dandandan]

This #12348 , I think I move the fix out of this PR, so it can be reviewed separately

[Dandandan]

#12404

[alamb]

do we have any benchmarks that pushing these into Filters is faster than evaluating them in joins?

I am surprised that the overhead of filtering (and this copying) all non-null rows outweighs the benefits

If the filter was pushed all the way to the scan, I could see it potentially helping. However, I don't see any plans where the filter is actually pushed into a scan (perhaps because all the tests operate on CSV / MemTable which don't support filters)

[alamb]

the link seems to be incomplete

[alamb]

Benefits: Input to join is smaller, so smaller input, faster build, no nulls need to be hashed

But in order to skip hashing nulls, the input array would have to be "filtered" (aka copy the matching rows)

lower chance for data skew, other join can be planned, downstream kernels are faster, can possibly be pushed down into scan, etc. In distributed setting, might save a lot of IO as well.

The argument in the distributed setting makes sense to me, but the other ones seem like they are all of the class "faster in some cases but slower in others"

[Dandandan]

But in order to skip hashing nulls, the input array would have to be "filtered" (aka copy the matching rows)

Correct, but you save some copying in RepartitionExec / build side concatenate as well, and copying / checking columns of keys in probe side.
In case there aren't any nulls (even if column is nullable), there is no copying happening.

Even with CSV / MemTable in many cases null filter can be combined with existing filter expressions, so no extra copying is happening (less copying in fact as fewer rows need to be copied).

[Dandandan]

do we have any benchmarks that pushing these into Filters is faster than evaluating them in joins?

I am surprised that the overhead of filtering (and this copying) all non-null rows outweighs the benefits

If the filter was pushed all the way to the scan, I could see it potentially helping. However, I don't see any plans where the filter is actually pushed into a scan (perhaps because all the tests operate on CSV / MemTable which don't support filters)

Thanks, I'll try and see if there are any benchmarks. I tried with TPCH, but there aren't any nulls in there so benchmarks aren't changed (as expected).