Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
Currently a long planning process (e.g. JdbcTest.testIn) seems to fire a lot of rules about merging projects with projects, projects with calcs. I suspect that there are a lot of sets that are equivalent but for a permutation of the order of the columns.
If each RelNode that was a member of a RelSet specified a permutation (possibly the identity) of its columns to match the order in the set, then many sets would be merged, and the search space would be much smaller.
ProjectRels and CalcRels that are just a permutation (not to mention renames and the identity) would be identified and removed when the rel is registered.
This change would increase complexity for people implementing rules. In addition to "RelNode RelOptRuleCall.rel(int)", there would be "Permutation RelOptRuleCall.permutation(int)", and we need to make sure that people remember to call permutation.
Today people have to remember to write variants of a rule that match rels with and without intervening projects. With this change, the intervening projects would be rarer, so the simple rules would be applicable in more cases.
---------------- Imported from GitHub ----------------
Url: https://github.com/julianhyde/optiq/issues/62
Created by: julianhyde
Labels: for-next-release,
Created at: Thu Oct 17 18:39:02 CEST 2013
State: open
Attachments
Issue Links
- is related to
-
CALCITE-55 Don't create sets that are just a column-permutation of an existing set
- Open
- relates to
-
CALCITE-404 MergeProjectRule should not construct RexPrograms for simple mappings
- Closed