One useful pattern for index scan is a table that accepts a stream of rowids as input. It isn't technically "correlated" - i.e. doesn't require a restart to get the next rowid.
As for optimizing queries to use indexes. I believe a good approach is to model the index as a sorted projection (i.e. a kind of materialized view) and a lookup as a join (somewhat like a sort-merge join) on the rowid pseudo-column. The Phoenix folks are just about to start optimizing queries for indexes, using some of the above ideas. Anyway, good topic for the hangout. Julian On May 9, 2015, at 14:10, Vladimir Sitnikov <[email protected]> wrote: >> I can force my query to run with a nestedloop(fullscan, >> indexscan) or would this involve changes to Calcite? > > If you put "forceDecorrelate=false" connection property, Calcite will > leave correlations in place. > "Correlate" is Calcite's term for "nested loop" > More details here: > https://github.com/apache/incubator-calcite/blob/e237804b0e4d7ac17249708a5cf823e0c1fe1625/core/src/main/java/org/apache/calcite/rel/core/Correlate.java#L51-60 > > Then you might want adding rules that swap table access with > correlated index scan. > >> I didn't know about the call, but yes, I'd like to join if it is an open >> invite. > > That's open. Follow this thread: > http://mail-archives.apache.org/mod_mbox/calcite-dev/201505.mbox/%3CCAB%3DJe-GdhkSbuYm0JF_O0D-Ez7qY8NNbQ%3DQrNwBDdFOA5%2BJQ2Q%40mail.gmail.com%3E > > Vladimir
