Perhaps I'm missing something, but I don't see why this would be any more efficient. Selecting all data is also not an efficient operation in Cassandra. Using ALLOW FILTERING will likely be more efficient since it's basically the same as doing a table scan, but it avoids returning data which would later be filtered by Calcite anyway. -- Michael Mior mm...@apache.org
Le jeu. 17 oct. 2019 à 09:13, Yanna elina <yannaelinasul...@gmail.com> a écrit : > > Thank for reply Michael. > > yes i understood this on the documentation for example with "WHERE" > statement calcite i force the . "ALLOW FILTERING; " > and this can be expensive. > > I think there may be an interesting approach using STREAM. > > for example maintain a regular update between a cassandra TABLE and a > STREAM TABLE. > > CASSANDRA_TABLE_A . (SELECT * FROM TABLE_A) --------> STREAM_TABLE_A . > SELECT STREAM * FROM STREAM_TABLE_A WHERE username = 'JmuhsAaMdw' > > i guess it will be more efficient to directly make the WHERE from the > STREAM than the cassandra_adapter using "allow filtering" > a synchronization strategy can be set up between the cassandra table and > the STREAM table > what is your opinion about this approach ? > Thanks ! > Yana > > > Le mer. 16 oct. 2019 à 17:08, Michael Mior <mm...@apache.org> a écrit : > > > 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 > >
