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.

NOTE: In draft because we want to coordinate with @joshua-spacetime about what will be the desirable testing changes...

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

[joshua-spacetime]

Can we make planning time external? So that we don't compute it during normal execution.

[mamcx]

So create a wrapper? Because the alternative is to parse EXPLAIN

[joshua-spacetime]

I just want to make sure we have the option not to time if we're not invoking the printer.

[joshua-spacetime]

Note: A double space at the end of a doc comment line is interpreted as a new line by the formatter.

[mamcx]

This spaces are removed by rustfmt

[joshua-spacetime]

These arrows should all have the same indentation, right?

[mamcx]

Which ones?:

Only the first two?

[joshua-spacetime]

The 1st, 3rd, and 4th lines should all have the same indentation, no?

-> Index Scan using Index id 0: (identity) on u
-> Inner Unique: true
-> Index Cond: (u.entity_id = p.entity_id)

[joshua-spacetime]

We don't have outer joins, so should this just be Unique: false instead?

[mamcx]

Well this is what the IxJoin pass.

[joshua-spacetime]

Suggested change

	-> Hash Cond: (m.manager = n.manager)
	-> Join Cond: (m.manager = n.manager)

[joshua-spacetime]

Suggested change

	Index Cond: (q.entity_id = b.entity_id)
	Join Cond: (q.entity_id = b.entity_id)

[mamcx]

This is consistent to how pg show the plan:

SELECT * FROM auth_user a JOIN auth_user b ON a.username = b.username where a.username = 'a'

 Nested Loop  (cost=0.29..16.34 rows=1 width=386) (actual time=21.830..21.831 rows=0 loops=1)
   Output: a.username, a.name, a.email, a.password, a.role, a.is_active, a.dot, b.username, b.name, b.email, b.password, b.role, b.is_active, b.dot
   ->  Index Scan using auth_user_pkey on betatest.auth_user a  (cost=0.15..8.17 rows=1 width=193) (actual time=21.829..21.830 rows=0 loops=1)
         Output: a.username, a.name, a.email, a.password, a.role, a.is_active, a.dot
         Index Cond: (a.username = 'a'::text COLLATE nd)
   ->  Index Scan using auth_user_pkey on betatest.auth_user b  (cost=0.15..8.17 rows=1 width=193) (never executed)
         Output: b.username, b.name, b.email, b.password, b.role, b.is_active, b.dot
         Index Cond: (b.username = 'a'::text COLLATE nd)

[joshua-spacetime]

In your example, Index Cond is an attribute of the Index Scan, not the join.