[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934792#comment-16934792
]
Scott Reynolds commented on CALCITE-963:
----------------------------------------
So took a break from being in this code base and came back with a fresh brain
and eyes. Went back over my original notes and noticed I hadn't explored what
{{EnumerableRelImplementor#stash}} method did. After reviewing that method I
determined that is *exactly* what I needed during code compilation. This method
takes an object stores it in {{DataContext}} and returns an {{Expression}} that
calls {{DataContext#get}} to pull out the object. This generates the same code
for each query of the format like:
{code:sql}
Select * from emp where empno = 1;
Select * from emp where empno = 2;
{code}
as it stashes all the predicates via {{EnumerableRelImplementaor#stash}}
This is awesome! and this pull request and design is objectively worse then
this implementation. So sorry for the digression in this ticket, it appears I :
a.) Don't understand what variable hoisting really is
b.) Didn't spend enough time researching and understanding all the tools
Calcite provides.
> 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: 0.5h
> 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
(v8.3.4#803005)
