Feature: Operator Printing

[andyfengHKU]

Description

As we approach the benchmark stage, plan printing is being used much more frequent. We need to make the following change to plan printing.

Stage 1: Print static information

The first step is to print operator static information correctly and thoroughly, e.g. what table is being scanned and what columns are being scanned ...

A complete list is as follow

• [x] SimpleAggregate
  • aggregate expressions
• [x] SimpleAggregateScan
  • N/A
• [x] HashAggregate
  • hash keys, hash payloads, aggregate expressions
• [x] HashAggregateScan
  • N/A
• [x] Alter
  • alter information, e.g. rename, add column, ...
• [x] Attach
  • database name
• [x] CopyFrom
  • table name and source, e.g. file name, subquery, ...
• [x] CopyTo
  • table name to file name
• [x] CreateMacro
  • macro name
• [x] CreateSequence
  • sequence name
• [x] CreateTable
  • table name and possible config
• [x] CreateType
  • type name
• [x] CrossProduct
  • N/A
• [x] Delete
  • expressions and possible config
• [x] Detach
  • database name
• [x] Distinct
  • expressions
• [x] DropSequence
  • sequence name
• [x] DropTable
  • table name
• [x] DummyScan
  • N/A
• [x] EmptyResult
  • N/A
• [x] Explain
  • Profile/Explain
• [x] ExpressionsScan
  • expressions
• [x] Extension
  • action and extension name
• [x] ExportDatabase
  • N/A
• [ ] Flatten
  • ideally we should print one expression to indicate which data chunk are we flattening
• [x] Filter
  • expression name
• [x] GDSCall
  • algorithm name
• [x] HashJoinBuild
  • key & payloads
• [x] HashJoinProbe
  • key
• [x] ImportDatabase
  • N/A
• [x] IndexLookup
  • index name (maybe table name)
• [x] Insert
  • expressions & action (e.g. ON CONFLICT DO NOTHING)
• [x] IntersectBuild
  • same as hash join build
• [x] Intersect
  • same as hash join probe
• [x] InstallExtension
  • extension name
• [x] Limit
  • number
• [x] LoadExtension
  • extension name
• [x] Merge
  • the pattern to merge
• [x] MultplicityReducer
  • N/A
• [x] OffsetScanNodeTable
  • N/A
• [x] Partitioner
  • ask @ray6080
• [x] PathPropertyProbe
  • path expression
• [x] PrimaryKeyScanNodeTable
  • path expression
• [x] Projection
  • expression names
• [x] Profile
  • N/A
• [x] RecursiveJoin
  • N/A
• [x] RenameProperty
  • from name to new name
• [x] RenameTable
  • same as above
• [x] ResultCollector
  • done
• [x] ScanNodeTable
  • table name, property names, zonemaps
• [x] ScanRelTable
  • table name, property names, direction, zonemaps
• [x] SemiMasker
  • scan operators that this semi mask is applying to
• [x] SetProperty
  • left = right
• [x] Skip
  • number
• [x] StandaloneCall
  • print cmd (ideally we want this to be a function name)
• [x] TableFunctionCall
  • function name
• [x] TopK
  • order by keys and payloads and K
• [x] TopKScan
  • N/A
• [x] Transaction
  • action
• [x] OrderBy
  • same as top K except for K
• [x] OrderByMerge
  • N/A
• [x] OrderByScan
  • N/A
• [x] UnionAllScan
  • N/A or expressions
• [x] Unwind
  • unwind expression as expression
• [x] UseDatabase
  • database name

Stage 2 Rendering

Rendering plan on shell is tricky when the plan becomes big. Plus it's not sufficient to just render it on the shell. We need a mechanism to render big plan on the web and in the explorer too. I don't have concrete road map for stage2 so @mewim should edit this part. One thing I'm fairly certain is that we need to first print plan to json format

• [ ] print plan to json (try to reuse our json feature instead of relying on third party)

Stage 3 Print logical plan

Since we have printed physical plan already, there is nothing prevent us from printing logical plan either.

We want the logical plan to print with a cypher command Explain Logical. It will process and print similar to the plan printer for the physical plan so we can adapt this code to print logical plans as well. The logical operators will need print info structs to handle the list of information below.

As well, since both physical operators and logical operators will have their own printing structs, we no longer need getExpressionsForPrinting().

• [ ] remove this function from every logical operator

A complete list for logical plan printing is as follows:

• [ ] Accumulate
  • N/A
• [ ] Aggregate
  • Keys, Aggregates
• [ ] Alter
  • alter information, e.g. rename, add column, ...
• [ ] Attach Database
  • database name
• [ ] Copy From
  • table name and source, e.g. file name, subquery, ...
• [ ] Copy To
  • table name to file name
• [ ] Create Macro
  • macro name
• [ ] Create Sequence
  • sequence name
• [ ] Create Table
  • table name and possible config
• [ ] Create Type
  • type name
• [ ] Cross Product
  • N/A
• [ ] Delete
  • expressions and possible config
• [ ] Detach Database
  • database name
• [ ] Distinct
  • expressions
• [ ] Drop
  • drop type, sequence name/table name
• [ ] Dummy Scan
  • N/A
• [ ] Empty Result
  • N/A
• [ ] Explain
  • N/A
• [ ] Expressions Scan
  • expressions
• [ ] Extend
  • table name, property names, direction, zonemaps
• [ ] Extension
  • action and extension name
• [ ] Export Database
  • N/A
• [ ] Filter
  • expression name
• [ ] Flatten
  • ideally we should print one expression to indicate which data chunk are we flattening
• [ ] GDS Call
  • algorithm name
• [ ] Hash Join
  • join conditions, join type
• [ ] Import Database
  • N/A
• [ ] Index Look Up
  • index name (maybe table name)
• [ ] Intersect
  • Keys, payload
• [ ] Insert
  • expressions & action (e.g. ON CONFLICT DO NOTHING)
• [ ] Limit
  • limit and skip number
• [ ] Mark Accumulate
  • keys, mark
• [ ] Merge
  • the pattern to merge
• [ ] Multiplicity Reducer
  • N/A
• [ ] Node Label Filter
  • N/A
• [ ] Order By
  • order by keys and payloads and K
• [ ] Partitioner
  • ask @ray6080
• [ ] Path Property Probe
  • path expression
• [ ] Projection
  • expression names
• [ ] Recursive Extend
  • Same as extend
• [ ] Scan Node Table
  • table name, property names, zonemaps
• [ ] Semi Masker
  • scan operators that this semi mask is applying to
• [ ] Set Property
  • left = right
• [ ] Standalone Call
  • print cmd (ideally we want this to be a function name)
• [ ] Table Function Call
  • function name
• [ ] Transaction
  • action
• [ ] Union All
  • N/A or expressions
• [ ] Unwind
  • unwind expression as expression
• [ ] Use Database
  • database name

Stage 4 Print statistics and cardinality

• [ ] Print estimated cardinality for logical plan
• [ ] Print actual cardinality for physical plan
• [ ] Propagate and print estimated cardinality to physical plan to see how off we are

Stage 5 Advanced statistics printing

I haven't decided if we should go this far. But printing disk IO for scan operators make sense to me.

[ray6080]

Not sure when we can get to stage2 and be able to visualize the plan in a web page. Alternatively, we can provide a more succinct way of printing the plan. One example is what Postgres does here, so it should work better in more cases, though readability decreases a lot.