Hi all, I have submitted my pull request in github and wrote up a design document as a comment on CALCITE-963 <https://issues.apache.org/jira/browse/CALCITE-963?focusedCommentId=16932829&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16932829>
My implementation deviates considerably from what is being discussed in this thread so I rushed it up so you all can let me know what I am missing. Here is a excerpt from the design document: Goal When a query is issued to Calcite it is parsed, optimized and then generates a String of Java Class that implements Bindable. EnumerableInterpretable creates this string and checks to see if that string exists in com.google.common.cache and if it doesn't it will call into a Java compiler. Compilation process can take a considerable amount of time, Apache Kylin reported 50 to 150ms of additional computation time. Today, Apache Calcite will generate unique Java Class strings whenever any part of the query changes. This document details out the design and implementation of a hoisting technique within Apache Calcite. This design and implementation greatly increases the cache hit rate of EnumerableInterpretable's BINDABLE_CACHE. Non Goals This implementation is not designed to change the planning process. It does not transform RexLiteral into RexDynamicParam, and doesn't change the cost calculation of the query. Please take a moment to read the design document let me know what you think. On Tue, Sep 17, 2019 at 12:27 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Stamatis>Out of curiosity does anybody know if popular DBMS (Postgres) > support "hoisting"? > > PostgreSQL does support it, and here's a reproducible case when that > feature makes the query 300 times slower: > https://gist.github.com/vlsi/df08cbef370b2e86a5c1 > > Vladimir >
