I agree with what Luis said. Also, remember that ProjectableFilterableTable is intended to be a simple solution for the simple, common cases. If you need something more complex you may need to write a rule.
Julian > On Oct 23, 2017, at 4:49 AM, Luis Fernando Kauer > <[email protected]> wrote: > > Hi, > Can you give us some examples of the queries you tested? Include the the > query plan Calcite generated. (Use EXPLAIN PLAN FOR you query) > Currently, aggregates with no column reference, like count(*), generates a > plan that scans all projects when using ProjectableFilterableTable. I'm not > sure it there is a Jira for that already. > The other option is to use TranslatableTable, but be aware that you'll have > to implement rules to push the necessary projects to the table scan, unlike > when using ProjectableFilterableTable which has many rules built in Calcite > for that. > See also:[CALCITE-1876] Create a rule to push the projections used in > aggregate functions - ASF JIRA > > Druid adapter calls Druid to execute the table scan. In CSV Adapter it is > executed by Calcite using Enumerator. > Always check the query plan first and create rules to optimize it the way you > want. > Enable tracing if you want to check which rules were applied. > > https://calcite.apache.org/docs/howto.html#tracing >
