[EPIC] Improving cost calculations and cost based optimizations

[isidentical]

Design document: https://docs.google.com/document/d/1M4mmV7KA1LSj-D-WJA338B4ydlm-8A8D5OPuDE5_SD4/edit

This is a meta issue for improving cost calculations and cost-based optimizations in DataFusion. We already have some statistics collected (mainly from the table sources) and there are estimations for statistics by some of the execution plan nodes, and the overall idea is to improve these as well as possible CBOs.

Main Goals

• Have enough statistics to start nested join optimizations (#3843). This involves being able to estimate the weight of a join side, and do global re-ordering between join sides to minimize the overall cost of parent joins by reducing the output as much as possible at the bottom levels.
• Provide a more reliable static analysis phase for physical execution operators (so that range based pruning/predicate pruning can leverage the existing infrastructure on their implementations)
• What else?

Work in Progress

• [x] https://github.com/apache/arrow-datafusion/issues/3898
• [x] https://github.com/apache/arrow-datafusion/issues/3845
• [ ] https://github.com/apache/arrow-datafusion/issues/4158
• [ ] https://github.com/apache/arrow-datafusion/issues/4159
• What else?

Planned

• [ ] Estimating join cardinalities when the underlying table does not have any statistics (https://github.com/apache/arrow-datafusion/issues/3813#issuecomment-1276643214).
• What else?

Future

• Support for histograms, so better value distribution when working with cardinality estimations / filter selectivity. Currently, none of the providers we use can directly pass it to us, so we either have to take a peek at the data or only expose the API for other services (like ballista) which can actually collect it and pass to us.

P.S.: feel free to update the text directly or let me know (and I can update it myself)

[isidentical]

@alamb @Dandandan @mingmwang I've created the meta/epic issue as we discussed

[alamb]

I believe the next step is some sort of design document.

[isidentical]

I'd be happy to start one, and if anyone is interested I can also give write access (shoot me your google emails at [email protected]).

[Dandandan]

Maybe you can share the doc publicly so anyone can do suggestions?

[isidentical]

It should be publicly accessible now: https://docs.google.com/document/d/1M4mmV7KA1LSj-D-WJA338B4ydlm-8A8D5OPuDE5_SD4/ (also pinning this to the issue)

It is an overall discovery of the stuff we are doing right now and how they can actually help us in the future (as well as some possible points) but it is in a very early stage. I'd be thrilled to hear about what you are thinking as well as potentially other unexplored areas).

[alamb]

I plan to review the doc carefully tomorrow ❤️

[isidentical]

Thanks @alamb! I'll also try to talk a bit more about it with real-world examples in tomorrow's meeting from scratch (if we would have the time for that in this meetup, and if I can actually make it there), just in case if anyone else here is planning to attend.