I am skeptical that RelWithHint will work for large queries. How do we introduce it in a reversible way? What are the other options?
> On Oct 10, 2019, at 1:29 AM, Danny Chan <[email protected]> wrote: > > 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 <[email protected]>，写道： >> 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 <[email protected]> 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/[email protected]: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 >>
