Julian, thanks so much for providing the reference and the historical note.
I have no strong objections for the table hints format you proposed, overall, the grammar look more unified and concise. Also many thanks for the suggestions of the code. Best, Danny Chan 在 2019年9月5日 +0800 AM10:43，Julian Hyde <jh...@apache.org>，写道： > A historical note. Microsoft SQL Server inherited its hint syntax from Sybase > a very long time ago. (See “Transact SQL Programming”[1], page 632, > “Optimizer hints”. The book was written in 1999, and covers Microsoft SQL > Server 6.5 / 7.0 and Sybase Adaptive Server 11.5, but the syntax very likely > predates Sybase 4.3, from which Microsoft SQL Server was forked in 1993.) > > Microsoft later added the WITH keyword to make it less ambiguous, and has now > deprecated the syntax that does not use WITH. > > They are forced to keep the syntax for backwards compatibility but that > doesn’t mean that we should shoulder their burden. > > I think formatted comments are the right container for hints because it > allows us to change the hint syntax without changing the SQL parser, and > makes clear that we are at liberty to ignore hints entirely. > > Julian > > [1] https://www.amazon.com/s?k=9781565924017 > <https://www.amazon.com/s?k=9781565924017> > > > On Sep 4, 2019, at 7:12 PM, Julian Hyde <jh...@apache.org> wrote: > > > > 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 > > >
