Out of curiosity does anybody know if popular DBMS (Postgres, Oracle, SQL Server, etc.) support "hoisting"?
Performing it all the time does not seem a very good idea (constant reduction, histograms, and other optimization techniques would be impossible) while leaving its configuration to the end-user may not be a straightforward decision. On Sat, Sep 14, 2019 at 4:29 PM Julian Hyde <jhyde.apa...@gmail.com> wrote: > 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? >
