Julian Hyde commented on CALCITE-963:

I looked at the PR briefly:
* I was surprised that HoistedVariables was added to so many API calls. Maybe 
it could belong to another piece of the preparation context?
* As a plural noun, HoistedVariables is a poor name for a class, in my opinion. 
An instance of HoistedVariables is an object (singular) so it will be difficult 
to write good javadoc sentences describing it. 
* I was surprised that this work touched so much Enumerable code. An 
alternative approach would be to transform a RelNode tree, early in the 
planning process, transforming some RexLiteral instances into RexDynamicParam. 
The rest of the planning process would proceed as if the user had provided a 
statement with bind variables. I know you state that this was a non-goal, but 
why was it not a goal? It probably would have been a lot simpler, and it would 
have worked with conventions besides Enumerable.

> Hoist literals
> --------------
>                 Key: CALCITE-963
>                 URL: https://issues.apache.org/jira/browse/CALCITE-963
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: HoistedVariables.png
>          Time Spent: 10m
>  Remaining Estimate: 0h
> Convert literals into (internal) bind variables so that statements that 
> differ only in literal values can be executed using the same plan.
> In [mail 
> thread|http://mail-archives.apache.org/mod_mbox/calcite-dev/201511.mbox/%3c56437bf8.70...@gmail.com%3E]
>  Homer wrote:
> {quote}Imagine that it is common to run a large number of very similar 
> machine generated queries that just change the literals in the sql query.
> For example (the real queries would be much more complex):
> {code}Select * from emp where empno = 1;
> Select * from emp where empno = 2;
> etc.{code}
> The plan that is likely being generated for these kind of queries is going to 
> be very much the same each time, so to save some time, I would like to 
> recognize that the literals are all that have changed in a query and use the 
> previously optimized execution plan and just replace the literals.{quote}
> I think this could be done as a transform on the initial RelNode tree. It 
> would find literals (RexLiteral), replace them with bind variables 
> (RexDynamicParam) and write the value into a pool. The next statement would 
> go through the same process and the RelNode tree would be identical, but with 
> possibly different values for the bind variables.
> The bind variables are of course internal; not visible from JDBC. When the 
> statement is executed, the bind variables are implicitly bound.
> Statements would be held in a Guava cache.
> This would be enabled by a config parameter. Unfortunately I don't think we 
> could do this by default -- we'd lose optimization power because we would no 
> longer be able to do constant reduction.

This message was sent by Atlassian Jira

Reply via email to