Hi, Julian, do you think we can make some effort to push this feature into release 1.22 ? The Flink community kind of need this feature in the near future.
The most controversial part is how to transfer the hints during planning phrase, my initial idea is: >To copy the hints automatedly in the method RelOptRuleCall#transformTo for the >new rel node from the >original rel node if both of them are all RelWithHint. I have added some simple planning test cases and it works as expected, but I’m not sure if this can fits all the corner cases(very probably not). The other part works great as the design doc describes. Best, Danny Chan 在 2019年9月5日 +0800 AM10:12，Julian Hyde <jh...@apache.org>，写道： > Thanks for continuing to push on this! > > I don’t much like the MSSQL-style syntax for table hints. It adds a new use > of the WITH keyword that is unrelated to the use of WITH for common-table > expressions. Instead of > > select /*+ NO_HASH_JOIN, RESOURCE(mem='128mb', parallelism='24') */ > from > emp with (INDEX(idx1, idx2)) > join > dept with (PROPERTIES(k1='v1', k2='v2')) > on > emp.deptno = dept.deptno > > could we do > > select /*+ NO_HASH_JOIN, RESOURCE(mem='128mb', parallelism='24') */ > from > emp /*+ INDEX(idx1, idx2) */ > join > dept /*+ PROPERTIES(k1='v1', k2='v2’) */ > on > emp.deptno = dept.deptno > > > In some of the classes you have public fields of type ImmutableList. This > makes it difficult to coexist in an environment that uses a different version > of Guava, or shades Guava. Probably better to make them of type List. (You > don’t need to change ImmutableBitSet; it’s not a Guava class.) > > There is one argument where a List<Integer> is assigned to an > ImmutableBitSet. Make it an Iterable<Integer>, and people can pass in an > existing ImmutableBitSet without copying. > > Julian > > > > On Sep 3, 2019, at 1:18 AM, Danny Chan <yuzhao....@gmail.com> wrote: > > > > Hi, fellows, I’m here again :) > > > > This time I want to have a full discussion about CALCITE-482, which is an > > issue fired at 27/Nov/14 by Vladimir Sitnikov. > > > > Almost every sql vendor supports sql hint for their production version DB > > engines, so it would be nice if we have a framework in Calcite to support > > this, so that the engines that built based on CALCITE would have the > > ability to extend and have their custom sql hint implementations. > > > > In April this year I have fired an initial discussion about this topic[1], > > and I’m glad that we have some agreements for the design. > > > > Recently I have fired a PR[3] and write a design doc[2] mostly based on the > > discussion[1], so feel free to give some feedback here so we can make the > > hint framework more flexible. > > > > Any suggestions are appreciated. > > > > > > [1] > > https://lists.apache.org/list.html?dev@calcite.apache.org:dfr=2019-4-1|dto=2019-4-30:How%20to%20traverse > > [2] > > https://docs.google.com/document/d/1mykz-w2t1Yw7CH6NjUWpWqCAf_6YNKxSc59gXafrNCs/edit?usp=sharing > > [3] https://github.com/apache/calcite/pull/1354 > > > > Best, > > Danny Chan >
