[Proposal] Volcano query planner

[tuannh982]

Description:

Originally I tried to separate the AST, the logical plan and physical plan from #5. But ended up doing both separation and propose a new query planner

Related issues (might be)

• Add logical plan between AST and execution #5
• Make or operator "smarter" #140
• "Aggressive" optimizations mode #66

Notes:

• This is a proposal PR. It's only mean to describe how it might look like, not a full implementation. Do not merge

[MichaHoffmann]

Im ++1 for seperating physical plan and logical plan! Since thats a pretty big undertaking already can we split out the Planner maybe so it gets more feasible?

[bwplotka]

Nice, quite a big refactor! Do you mind starting a quick discussion on #thanos-dev Slack channel about this? We could discuss it further. We would love to learn your use cases and plan with this advanced promql engine. Theory is one thing, but in practice it's hard to estimate true cost without knowing how much data we will have to fetch. We had some initial ideas to perform two-phase query (scan, fetch) but it's not there yet.

[tuannh982]

@bwplotka thanks for reminding me, I will post this to #thanos-dev Slack channel for further discussion 👍