bq. Any optimizer folks out there interested in getting involved? Some oracle expert team is available here James. Hope they will help if needed.
Thanks, Rajeshbabu. On Thu, Jan 30, 2014 at 10:00 PM, James Taylor <[email protected]>wrote: > It's on our roadmap, but we need to collect stats first to drive optimizer > decisions on whether joining back to the data table is more efficient than > just doing a full table scan of the data table. > > Any optimizer folks out there interested in getting involved? > > Regards, > James > > On Thursday, January 30, 2014, Jesse Yates <[email protected]> > wrote: > > > AFAIK, no one is working on this, but it sounds pretty cool! > > > > Mind filling a JIRA? > > > > Thanks, > > J > > On Jan 30, 2014 7:28 AM, "rajeshbabu chintaguntla" < > > [email protected] <javascript:;>> wrote: > > > > > Hi, > > > > > > Normally when we want to use secondary indices we create index on one > or > > > very few > > > columns of interest in query conditions. Index may not contain all the > > > columns to retrieve. > > > > > > Currently Phoenix supporting full covered indexes only(where all or > most > > > of the columns > > > should be in the index in many cases). When we run a query we will > choose > > > to scan from user table > > > or index table based on condition that whether all projected columns > in > > > the index or not. > > > This approach may have some disadvantages mainly in case of wider > tables. > > > 1)If we did just store all the columns in the index, then it would be > > just > > > like creating another copy of the entire table > > > - which would take up way too much space and would be very inefficient > > > for wider tables. > > > 2) Some times if user creates index on few columns and observes that > > index > > > is not getting used > > > and then he need to add all the projected columns to index(may be to > the > > > part of index or included columns). > > > which is something like we are exposing design decisions to the users, > > > especially when we already > > > target to simplify user's experience by giving SQL on top of a noSQL > DB. > > > 3) One more thing is as of now if we have an index table contains all > > > projected columns in the > > > query then we are simply scanning index table only.This can also become > > > full table scan when we don't > > > have any condition in the query or condition on non primary key column > of > > > index. > > > Some times this might give bad performance than normal table full scan. > > > > > > Any one working to make use of partial covered indexes to avoid full > > table > > > scan? > > > > > > We are interested to work on this in Phoenix. > > > > > > As part of our local indexing solution, we have similar kind of > support. > > > From index table first we fetch main table row key and from that we get > > > projected columns data from main table so that we can skip most of > > records > > > to scan from main table. > > > > > > Thanks, > > > Rajeshbabu. > > > > > > > > > > > > > > > > > > > > > > > >
