Hi Vamsi, A couple of thoughts:
* You could enable compression on the HBase table and not compress your data by hand * If you do store compressed records, are users running queries that need to run against the uncompressed form of those records? Or are they just querying metadata that is not compressed (and thus can be queried normally by Phoenix)
Given what you described, you might have better luck extending the Avatica JDBC driver to just decompress some records on the client-side before returning them to the caller instead of trying to re-build all of Phoenix in Calcite.
Vamsi Thattikota wrote:
Greetings, I'm new to Apache Calcite. I have a question about a few things. Before I ask, I want to say this is a great project. I have a requirement where I have to store data in a compressed form in HBase. And I'm going through the Apache Phoenix driver to interact with HBase and I'm pushing the compressed records into HBase using the Phoenix jdbc driver by writing a small java program. However, the read requirement of this data is a little different. The data needs to be uncompressed and returned. However, the end user can only use a jdbc driver to interface with the data. I looked into the Phoenix UDF approach, but it has limited support. It looks like the above can be implemented using something like a proxy jdbc driver. Which is where Apache Calcite can help. I got the latest Calcite code and built it and debugged the samples to a good extent. However, I have a few questions before I take this approach. If I expose these tables as a TranslatableTable or a FilterableTable, can I implement relational operators? The reason is I want to be able to access the query the user issued so that I can limit the data I'm fetching from Phoenix and uncompress it. I looked into the various calcite core test examples about RelBuilders. But, I don't yet understand how to connect these builders to the Translatable or Filterable table implementation. My apologies if I'm not asking the right question. Regards, Vamsi Thattikota.
