Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
I've gotten feedback over time saying that it's very difficult to grok our explain command. There's supposedly a lot of information that mainly matters to developers or the testing framework. Comparing it to other major DBs it does seem like we're packing way more into explain than other folks.
I've gone through the explain checking, what could be done to improve readability. Here's a list of things I've found:
- AST (unreadable in it's "lisp" syntax, not really required for end users)
- Vectorization (enough to display once per task and only when true)
- Expressions representation is very lengthy, could be much more compact
- "if not exists" on DDL (enough to display only on true, or maybe not at all)
- bucketing info (enough if displayed only if table is actually bucketed)
- external flag (show only if external)
- GlobalTableId (don't need in plain explain, maybe in extended)
- Position of big table (already clear from plan)
- Stats always (Most DBs mostly only show stats in explain, that gives a sense of what the planer thinks will happen)
- skew join (only if true should be enough)
- limit doesn't show the actual limit
- "Alias -> Map Operator tree" -> alias is duplicated in TableScan operator
- tag is only useful at runtime (move to explain extended)
- Some names are camel case or abbreviated, clearer if full name
- Tez is missing vertex map (aka edges)
- explain formatted (json) is broken right now (swallows some information)
Since changing explain results in many golden file updates, i'd like to take a stab at all of these at once.