Replies: 7 comments 9 replies
-
|
... this issue may also be discussed in a border context. For example, how to support hidden column in our optimizer? |
Beta Was this translation helpful? Give feedback.
-
|
I think we can summarize the benefits of making optimizer/planner hidden-column aware, if any. |
Beta Was this translation helpful? Give feedback.
-
|
-1, I don't think here we need is a hidden column in computing, row handler is just "hidden" in binder and the optimizer will treat it and other columns in the same |
Beta Was this translation helpful? Give feedback.
-
|
I think current solution of handling The proposal looks elegant to me. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I'm quite concerned with sub-queries... At that time, the un-nested queries can be converted into things that normal people won't write in SQL. I guess we will miss some cases for row_handler. |
Beta Was this translation helpful? Give feedback.
-
+1 |
Beta Was this translation helpful? Give feedback.
-
|
The proposal looks great, meanwhile, it seems we already have the general |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the column pruning framework mentioned in this discussion is exactly the prune_col functionality added days before. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Good idea! I've never thought about using a constant count to do count(*). |
Beta Was this translation helpful? Give feedback.
-
Why do we handle this special case in executor instead of optimizer? |
Beta Was this translation helpful? Give feedback.
-
|
This is expected to be handled in optimizer. I've changed it to
|
Beta Was this translation helpful? Give feedback.
-
|
I mean, after pruning the columns, we add rowhandler if there are no columns. |
Beta Was this translation helpful? Give feedback.
-
|
After we regard If so, maybe we don't even need to consider RowHandler as usual column in optimizer, because there are just no RowHandler columns... We just add an empty check in |
Beta Was this translation helpful? Give feedback.
-
|
Looks good! |
Beta Was this translation helpful? Give feedback.
-
|
Adding empty check in |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Related issues and PRs:
count(*)in binder #388It seems that
count(*)and row handlers are causing too many problems for us... The underlying cause it that:count(*)? This is a hard question. For example,select count(*) from tablerequires us to scan arbitrary column, whileselect count(*) from table where x = 1requires us to scanx, andselect count(*) from a join b on xxxrequires us to scan on the joined table...count(*)with row handler? We have hand-wired a lot of rules in binder and planner.Also, the RowHandler currently serves two purposes in our system:
delete from tablerequires a rowhandler to insert delete vectors (aka. delete tombstones).count(*)can be optimized to issue no I/Os on user column byrowcount(rowhandler).Therefore, I propose to move all such logics into the optimizer column pruning framework.
RowHandlercolumn, we should regard it the same as the user column in optimizer.count(*),we should regard it as counting on all columnsWe should regard it asrowcount(a, b, c, ..., rowhandler)in binder, and later optimize it into eitherrowcount(rowhandler)orrowcount(other column).count(1).count(*)).RowHandlercolumn.Any ideas? cc @st1page @Fedomn @xxchan
Beta Was this translation helpful? Give feedback.
All reactions