GH-4878 optimise sub-select

[hmottestad]

GitHub issue resolved: #4878

Briefly describe the changes proposed in this PR:

---

PR Author Checklist (see the contributor guidelines for more details):

• my pull request is self-contained
• I've added tests for the changes I made
• I've applied code formatting (you can use mvn process-resources to format from the command line)
• I've squashed my commits where necessary
• every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change

[hmottestad]

Develop branch

Benchmark                                                     Mode  Cnt    Score    Error  Units
QueryBenchmark.complexQuery                                   avgt    5    1.026 ±  0.024  ms/op
QueryBenchmark.different_datasets_with_similar_distributions  avgt    5    0.475 ±  0.003  ms/op
QueryBenchmark.groupByQuery                                   avgt    5    0.591 ±  0.002  ms/op
QueryBenchmark.long_chain                                     avgt    5  165.798 ±  2.056  ms/op
QueryBenchmark.lots_of_optional                               avgt    5   42.455 ±  0.284  ms/op
QueryBenchmark.minus                                          avgt    5  896.323 ± 26.089  ms/op
QueryBenchmark.nested_optionals                               avgt    5   62.486 ±  0.219  ms/op
QueryBenchmark.pathExpressionQuery1                           avgt    5    5.174 ±  0.081  ms/op
QueryBenchmark.pathExpressionQuery2                           avgt    5    0.491 ±  0.003  ms/op
QueryBenchmark.query_distinct_predicates                      avgt    5   51.896 ±  0.587  ms/op
QueryBenchmark.simple_filter_not                              avgt    5    2.072 ±  1.333  ms/op

This branch

Benchmark                                                     Mode  Cnt    Score    Error  Units
QueryBenchmark.complexQuery                                   avgt    5    1.061 ±  0.004  ms/op
QueryBenchmark.different_datasets_with_similar_distributions  avgt    5    0.472 ±  0.002  ms/op
QueryBenchmark.groupByQuery                                   avgt    5    0.606 ±  0.003  ms/op
QueryBenchmark.long_chain                                     avgt    5  172.897 ± 18.938  ms/op
QueryBenchmark.lots_of_optional                               avgt    5   44.313 ±  3.020  ms/op
QueryBenchmark.minus                                          avgt    5  914.117 ± 23.632  ms/op
QueryBenchmark.nested_optionals                               avgt    5   64.688 ±  2.071  ms/op
QueryBenchmark.pathExpressionQuery1                           avgt    5    5.386 ±  0.596  ms/op
QueryBenchmark.pathExpressionQuery2                           avgt    5    0.478 ±  0.027  ms/op
QueryBenchmark.query_distinct_predicates                      avgt    5   53.481 ±  1.733  ms/op
QueryBenchmark.simple_filter_not                              avgt    5    1.878 ±  0.519  ms/op

[hmottestad]

@JervenBolleman Any chance you could take a look at this PR? I made a test, but I didn't make a benchmark query yet. The benchmark run I did shows that there at least doesn't seem to be any performance degradation.

[JervenBolleman]

I think this is a good improvement and worth committing even without a benchmark query. A one of diff test is fine by me.

[JervenBolleman]

Should we not have + LINE_SEP instead of \n to be consistent?

[hmottestad]

isEqualToNormalizingNewlines fixes the new line seperators for us

[hmottestad]

But might change it back actually, since it's the only place that tests the line separation aspect of the query plan.

[JervenBolleman]

Thanks for catching this typo. Should we extract this into an utility at somepoint?

[hmottestad]

Could be moved to a more common module, but I don't think I want to do that now.

[JervenBolleman]

This looks like a nice improvement in the query plan.

[hmottestad]

@JervenBolleman I actually found out that the QueryJoinOptimizer is able to optimise sub-selects, but not if there are multiple sub-selects or if there are any BIND clauses anywhere. I've made two benchmarks that will make sure that we don't break that optimisation later.