The idea of converting literals into bind variables is called “hoisting”. We had the idea a while ago but have not implemented it.
https://issues.apache.org/jira/browse/CALCITE-963 Until that feature is implemented, you will need to create bind variables explicitly, and bind them before executing the query. Julian > On Sep 13, 2019, at 4:39 PM, Scott Reynolds <sdrreyno...@gmail.com> wrote: > > Hi, > > Spent a bunch of time researching and staring at code today to understand > the code compilation path within Calcite. I started down this path because > we noticed whenever we changed the `startDate` or `endDate` for the query > it went through compilation process again. We expected it to use the > previous classes `bind` it with the new RexLiterals. I was *hoping* the > RexLiterals were passed into the `bind()` method but that does not appear > to be the main goal of `DataContext` objects. > > We also found the trick Kylin did to improve their query compilation with > prepared statements: > https://issues.apache.org/jira/browse/KYLIN-3434 but PreparedStatement is > stateful and I don't believe a good way to solve this issue. > > I would like to propose a change to Calcite so that Filters are passed into > the `bind()` call alongside or within DataContext. This would allow the > `EnumerableRel` implementations to reference the `Filters` as arguments. > This -- I believe -- would cause any change to the filters to use > the previously compiled class instead of generating a brand new one. > > I am emailing everyone on this list for two reasons: > 1. Is this a bad idea ? > 2. I don't have a design yet so would love any ideas. Should we stick more > stuff into `DataContext`? Should `EnumerableRel` have another method that > is used to gather these RexLiterals?
