You're right that there are several types which are not supported by the Cassandra adapter. We would happily accept pull requests to add support for new types.
You're also correct that Cassandra cannot efficiently execute queries which do not specify the partition key. Calcite will make those queries more efficient, but it can make it easier to execute queries that CQL does not directly support. Ultimately data is still stored based on the partition key, so if your query does not specify a partition key, Calcite will still need to issue an expensive cross-partition query to Cassandra. -- Michael Mior mm...@apache.org Le mer. 16 oct. 2019 à 07:57, Yanna elina <yannaelinasul...@gmail.com> a écrit : > > Hi guys , > > I study Calcite the benefits that a Cassandra-Calcite Adapter can bring , > as for example brings the possibility of join. > > the problem type defined into CassandraSchema.getRelDataType(..) is very > limited > some important type are missing boolean / array ect... > > I thought inherited from the class CassandraSchema for Override this > method and add more type but this method is used inside CassandraTable too. > > i would like to avoid to re-write fully this adapter :) > > do you have suggestions? > > My second question is : Cassandra is not optimized to have WHERE on key > not defined on cluster/partition key. I was wondering if calcite could play > a role without this mechanism to improve performance > > > Thank ! > > Yanna
