Epic: `Plan` (replacing `LayoutReader`s)

[joseph-isaacs]

This Epic is for tracking the migration from LayoutReader to Plan to new system similar to how Arrays split out reducing and execution). This epic will focus on Plan optimisation (another epic will focus on the need compute and I/O and maybe subtasks). This Plan could be seen as a usual database physical plan.

We currently have a LayoutReader which operates on expressions using filter_evaluation, projection_evaluation etc. These are given an expression which they pass split up and pass into children LayoutReader. A Plan will act similarly to ArrayRef in that optimisations will rewrite one Plan into another.

Why

Currently there are a few problems with LayoutReader (some with execution, omitted here) and other with optimization.

1. Its currently hard to understand that a LayoutReader actually executes for a specific split (its internal to a stack frame) and the expression splitting is merged with execution.
2. Optimisations for an expression must be computed (with a cache) for each access to a split.
3. Its currently hard to modify the LayoutReader with modify the backing Layout (if I want to gate loading a file based on a pruning layout then I need to modify the layout tree when I should only need to modify the Plan).

What

A Plan will be a data structure with children [Plans], and segment, like how Arrays have children and buffers.

A plan will be created from a Layout augmented with other Plans optimised and then executed (this will be refined later).

Example

Lets say we have a Layout

StructLayout(a: FlatLayout, b: FlatLayout) and we want to apply the expr $.a + 1 the struct layout reader would be passed that expr partition the expression request $+1 from the a: FlatLayout and return it.

In the Plan system we would create

ExprPlan(
  expr: $.a+1
  child:
    StructPlan(
    a: FlatLayout
    b: FlatLayout
  )
)

which would be optimised to

p := ExprPlan(
  expr: $+1
  child: FlatLayout // flat layout reader from struct field a
)

p would then be evaluated using some out of scope execution system. (For now we will use the LayoutReader system we have in vortex)

Status

• Add a Plan trait
• Add a ExpressionPlan Tracking Issue: ExpressionPlan #9115
• Add custom pushdown for ExpressionScanPlan x ScanPlan (Struct, Dict, etc...)

Goal

• Move to Scan from using LayoutReader API to ScanPlan API
• Find and use a new execution system for Scan Plans. This wip: layout -> plan draft #8954 or something else.

Motivation

• This will give us control of expression/aggregation and other pushdown.
• The changed executor will give us control over resource usage.

Unresolved questions

• None yet.