each node in the relation tree must be able to provide the schema of the relation it represents.
So in our case we should let the exps contains the schema, so the exps in the transpose node in relation tree should contain the placeholder, while we should have another place for order schema and application schema
How to correctly expand the placeholder and the specific selection to fully quailfied name, what should be the relation name?
A: We force user to give transpose an alias. that way we make sure the fully qulified name are always working. We also don’t check the validity of the column reference at this time. User will also have to use fully qualified name on selection
For concrete selections like select a from tra(people) we ignore validity check at sql_rel level and at MAL level the invalid selection will perform an invalid projection
Select from not only the transpose but also others?
As we now force the user to give an alias to the transposed relation, we can at least match the reference of qualified name at relation level. so if the column store comes above transpose have the correct alias name of the transpose, we let it pass, otherwise we take it as invalid column reference
Also when the optimizer tries to push down expressions, it should not push down the column references to the transposed columns
For transpose that is above another N transposes.
The ordering schema is still specified by user → we can match it at relation level and the user need to use the fully qualified name → the modification of column matching we mention in section 1 will cover this
The application schema will be underdetermined, but we can identify two circumstances, First, the order schema is from the determined columns, Second, the order schema is from also the transposed columns
For the first situation, we can just include the transpose place holder from the transpose below into the application schema, for the second situation, we append those determined columns as application part, and we introduce a new column name called PLACE_HOLDER_SUB to represent that the application part from the transposed columns from transpose below it
r: a,b,c
a = 9 ,b = 10, c = 11
tra(tra(r by a) as T by T.9) as S
inner tra: os: r.a as: r.b, r.c result: T.$
3.1 How should deal with selection above joins of transpose with other relations? We let the transpose placeholder to “float up” with the relation tree, and use the match rule we mentioned in seciton 1
3.2 How should we deal with the join specs of joins
For theta joins, users specifies the join specs, we just use the matching rules mentioned above
For natural joins,
Currently what does the pipline do:
In relation plan part
1. Create join node with exps containing the join specs. 2.Create a project node above join node, get expressions for both side of the join and find try to find common columns between two, append one of the common column to the output relation expressions, and also append the rest of the columns to the expression.
In MAL part
Our approach:
In relation plan level
For thetajoins, it becomes the problem of column matching, so we use the solution of projection described in the first section
For natrual joins, if either side of the joins contains columns after transposition, we let match and later in the MAL we use a new MAL function to decide if the columns after transposition is joinable
In MAL level,
For thetajoins, just use the projected result of column ref as the input of algebra.join
For natural joins, we need first to identify the columns after transposition are with valid joinable columns, this case we need maybe a new MAL function or control flow, then pass the joinable columns into algebra.join
Relation plan level
There will be the following circumstances