Printer for the plan, ie: EXPLAIN

[mamcx]

Description of Changes

Incipient support for EXPLAIN with close plan output as in Postgres (but not yet conformant).

It has the extra capability of showing extra metadata about the schema & indexes, useful for testing & debugging.

Example:

-- Without metadata
Nested Loop
  -> Index Scan using Index id 0: (employee) on m
    -> Index Cond: (m.employee = U64(1))
  -> Seq Scan on p
  Output: id, name
Planning Time: 541.5µs

-- With metadata
Query: SELECT m.* FROM m CROSS JOIN p WHERE m.employee = 1
Nested Loop
  -> Index Scan using Index id 0: (employee) on m:1
    -> Index Cond: (m.employee = U64(1))
  -> Seq Scan on p:2
  Output: id, name
Planning Time: 527.666µs
-------
Schema:

Label m: 1
  Columns: employee, manager
  Indexes: Unique(m.employee)
Label p: 2
  Columns: id, name
  Indexes: Unique(p.id)

Closes #2058.

API and ABI breaking changes

None

Expected complexity level and risk

1

Testing

• Adding testing for both optimized or not variations of the plan
• WILL NEED more test but is likely that we need to do another pr

[bfops]

Is this achieving the same thing as #2065 ?

[mamcx]

Is this achieving the same thing as #2065 ?

No, this is for print the sql aka EXPLAIN SELECT... that other is for show the steps of migrations

[bfops]

I'm removing myself as a reviewer, because there is no longer any review for the files that I am a CODEOWNER of.

[joshua-spacetime]

Suggested change

// TODO: This should return product![2u64]

Aggregates are applied before LIMIT.

[joshua-spacetime]

I think I would like this to look something like:

Index Join
    Output: (b: RowId (table: b))
    Index: <index name> (table: b, unique: true)
    Index Cond: q.entity_id
    -> Index Join
        Output: (q: RowId (table: b))
        Index: <index name> (table: l, unique: false)
        Index Cond: p.chunk
        -> Index Join
            Output: (p: RowId (table: l))
            Index: <index name> (table: l, unique: true)
            Index Cond: u.entity_id
            -> Index Scan
                Output: (u: RowId (table: u))
                Index Cond: (identity = U64(5))

or

Index Join using <index name> on b
    Output: (b: RowId (table: b))
    Index Cond: q.entity_id
    -> Index Join using <index name> on l
        Output: (q: RowId (table: l))
        Index Cond: p.chunk
        -> Index Join using <index name> on l
            Output: (p: RowId (table: l))
            Index Cond: u.entity_id
            -> Index Scan using <index name> on u
                Output: (u: RowId (table: u))
                Index Cond: (identity = U64(5))

I.e., I want to know the index id or the index name that is being probed in an index join. I also want to know if an operator is returning row pointers vs product values.

[joshua-spacetime]

I don't think this is correct. This looks like the plan before it is optimized. Most of these hash joins should be index joins and the sequential scans should be index scans or index probes.

[joshua-spacetime]

Suggested change

	Limit: 5
	-> Seq Scan on t
	Output: t.x, t.y"#]],
	Limit: 5
	Output: (t: RowId (table: t))
	-> Seq Scan on t"#]],

I know this is a deviation from pg, but I find it much easier to read if the output comes before the input. In particular for left deep joins.