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. Eigenbase used a different strategy to plan queries (not materialized views). Also, Eigenbase tended to use hash-based algorithms (hash join, hash aggregation, bloom filters), applying sort only towards the end of query evaluation, and so the optimization process was less oriented to sort orders. Julian > On Aug 22, 2017, at 8:14 PM, Kaiwang Chen <kaiwang.c...@gmail.com> wrote: > > 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 historical docs there was a FennelIndexSearchRel > which I guess did similar job, as described in the 4th picture in this link > http://farrago.sourceforge.net/api/net/sf/farrago/query/package-summary.html#package_description > However, farrago-0.9.0 source code does not contain that class. Would you > please tell the design choice? > > Thanks, > Kaiwang > > > 2017-08-23 2:44 GMT+08:00 Julian Hyde <jh...@apache.org>: > >> 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 Emp followed by a sort, (b) a scan of >> I_Emp_DeptNo - and choose whichever has the cheapest plan. >> >> Details in this talk: https://www.slideshare.net/ >> julianhyde/costbased-query-optimization-in-apache- >> phoenix-using-apache-calcite <https://www.slideshare.net/ >> julianhyde/costbased-query-optimization-in-apache- >> phoenix-using-apache-calcite> >> >> Julian >> >>> On Aug 16, 2017, at 10:36 AM, Kaiwang Chen <kaiwang.c...@gmail.com> >> wrote: >>> >>> 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 TableScan is not a good one. A table scan is usually the worst >>> access path; any relation operator above table scan adds additional cost. >>> An index scan can be better, which firstly use the index to locate a >> range >>> of rows, then access each row with random IO. >>> >>> By the way, in MySQL, there is a greedy search tries almost all kinds of >>> orderings, and during the search it also choose the best access path of a >>> table. >>> >>> Thanks, >>> Kaiwang >> >>
