Development of Calcite integration is occurring on Phoenix’s “calcite” branch.
FennelIndexSearchRel is ancient history. Eigenbase had column store tables and
bitmap indexes implemented in C++; even though Calcite is descended from the
Eigenbase code, it no longer has its own storage structures.
Thanks Julian.
The example discussed materialized view for covering index for a query. How
to handle a non-covering query?
By the way, I found the Phoenix master branch contains no dependency on
calcite other than avatica. What's the status of the solution in the talk?
Additionally, according to
Phoenix project solves this problem by modeling indexes as materialized views
that are sorted projections of the base table. Thus if you execute
select deptName from Emp order by deptno
and there is an index I_Emp_DeptNo on (deptno, deptName) Calcite will consider
two plans - (a) a scan of
Hi there,
HepPlanner chooses the one with smallest Cumulative Cost from
transformations by a rule. LoptOptimizeJoinRule searches for the best
ordering of a MultiJoin. How to consider indices during the search? Is
there any RelNode that is suitable to hold physical access path?
Looks like
