See https://issues.apache.org/jira/browse/CALCITE-584 and in particular my comment starting 'Here is how I see the relationship between "scannable" and "query able”.’
The goal is to change the the convention of the root node (i.e. the exit point) of a query from Enumerable to Bindable. Then we will be able to move the Enumerable adapter into its own module, and use the simpler-but-slower interpreter if people want to execute queries using just core. It will also make core smaller and simpler. ENABLE_BINDABLE will be false until we switch the convention of the root node to Bindable. The Enumerable vs. Bindable choice also comes into play at the leaves of the tree, i.e. the table scans. But it we won’t be making such a clear transition. The convention by which we read a table will continue to be a dialog with that table, and how it prefers to produce its output. Most people find it easier to implement a bindable convention, say ScannableTable, but if you want performance you should go for another option, say TranslatableTable. If you are implementing an engine, as opposed to merely an adapter, you may want to define a convention and use it throughout the whole query, with the possible exception of the leaves. Drill, Hive and I suspect Samza will be in that category. Julian On Feb 11, 2015, at 5:22 PM, Milinda Pathirage <[email protected]> wrote: > Hi devs, > > When I'm trying to integrate Calcite to Samza's streaming query planning > phase, I saw there are two different set of rules for bindable convention > and enumerable convention. And ENABLE_BINDABLE is always 'false'. > > Does this convention effect the query planning decisions other than > transformations like LogicalTableScan to BindableTableScan or > EnumerableTableScan? > > Thanks in advance, > Milinda > > > -- > Milinda Pathirage > > PhD Student | Research Assistant > School of Informatics and Computing | Data to Insight Center > Indiana University > > twitter: milindalakmal > skype: milinda.pathirage > blog: http://milinda.pathirage.org
