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 > >
