This is as far as it got: https://issues.apache.org/jira/browse/CALCITE-1358 <https://issues.apache.org/jira/browse/CALCITE-1358>
The time dimension table would need to exist (but could be an in-memory table in Calcite — after all, 10 years is small, only 3,600 rows). Calcite would need to know that the “the_year” column was equivalent to “extract(year from __time)”, probably using some materialized view magic. The idea is that references to columns in the date dimension table get rewritten to expressions on “__time”, and then when no columns of the date dimension table are referenced it can be dropped from the query (using the foreign key/primary key semantics that come with lattices). Therefore you end up just using the Druid table. Julian > On Jan 23, 2017, at 2:22 PM, Gian Merlino <[email protected]> wrote: > > Do you have any docs or examples or suggestions around how that could be > done? It does sound like it'd be useful but I don't know where to start. > > Gian > > On Mon, Jan 23, 2017 at 12:19 PM, Julian Hyde <[email protected]> wrote: > >> >>> On Jan 23, 2017, at 12:14 PM, Gian Merlino <[email protected]> wrote: >>> >>> I bet you could also write some cool Calcite rules to make a phantom >>> "dimdate" table available, and convert joins on that table into >> application >>> of Druid native time functions on the base table. That'd allow the first >>> SQL query to work in an efficient way. >> >> That would indeed be cool (and useful). >> >> If you define a Calcite lattice of, say, a sales and time_by_day tables, >> backed by a Druid table, then Calcite will endeavor to convert join queries >> into queries on the Druid table. Those Druid queries will not be joins. >> >> Julian
