-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Simpler to see expressions in explain tree
mode
#15163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thank you @irenjj - I will check this out tomorrow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much @irenjj -- this looks really nice ❤️
I left some documentation suggestions.
Other than that, can you please hook up this format to one of the TreeExplain implementations so we
- Can see what a plan would look like
- Make sure the API is usable
Thanks @alamb , have added an example for Projection, it looks better than before. |
22)┌─────────────┴─────────────┐ | ||
23)│ SortExec │ | ||
24)│ -------------------- │ | ||
25)│ v1@0 ASC NULLS LAST │ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eventually it will be great to remove the @0
here too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can file a follow on PR to improve other plans 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I'd like to fix the expression printing format for all these plans in the next PR, since most plans' printing format are supported, filed #15238.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @irenjj -- I took the liberty of pushing some commits to this branch to:
- rename
sql_formatter
tofmt_sql
and added documentation / example - Cleaned up the printing of
ProjectionExec
Let me know what you think!
24)│ files: 1 │ | ||
25)│ format: csv │ | ||
26)└───────────────────────────┘ | ||
04)│ count(Int64(1)) ROWS │ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
formatting this as 1
rather than Int64
will be great eventually too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good idea! The output format of count(Int64(1))
is not controlled by fmt_sql
, it's a column generated by AggregateExec
, I'll try to resolve it in next pr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The output of AggregateExec
also seems to contain redundant information.
I debugged the code and found that the name of AggregateFunctionExpr
is constructed in create_aggregate_expr_and_maybe_filter
. In this function, debug information is generated for all Expr
instances through Expr
's SchemaDisplay
.
To address this issue, I propose the following solution:
- Add a new member
sql_name
toAggregateFunctionExpr
. - Introduce a new method
fmt_sql_name()
forExpr
, similar toschema_name()
, and override it inAggregateFunction
to generatesql_name
. - Modify
fmt_as
inAggregateExec
to outputaggr_expr.sql_name
instead ofaggr_expr.name
.
I'm not sure if this idea is correct. If you have any suggestions, that would be even better.❤️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this idea is correct. If you have any suggestions, that would be even better.❤️
I am not sure either -- maybe we can try it and see how it looks
@@ -379,3 +396,53 @@ where | |||
|
|||
DisplayWrapper(exprs.into_iter()) | |||
} | |||
|
|||
/// Prints a [`PhysicalExpr`] in a SQL-like format |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the code here and added an example
tree
mode
Thanks again @irenjj |
Which issue does this PR close?
tree
explain mode #15107Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?