; > > > > > >
> > > > > > > Julian,
> > > > > > > Your concern is very valid, and that is also our main concern.
> > > > > > > I was thinking whether we can put hint into the MEMO group, so
> > that both logical and physical e
can share the
> same hint, without copying the hint explicitly. But for newly generated
> expression that doesn't belong to the original group, we still need to copy
> hints. What's worse, in HepPlanner, there is no such concept, we may still
> need to copy hints explicity in planner r
> > > > > I was thinking whether we can put hint into the MEMO group, so that
> > > > > both logical and physical expression in the same group can share the
> > > > > same hint, without copying the hint explicitly. But for newly
> > > > > generated expres
and physical expression in the same group can share the same hint,
>>>> without copying the hint explicitly. But for newly generated expression
>>>> that doesn't belong to the original group, we still need to copy hints.
>>>> What's worse, in HepPlanner, there is n
re is no such concept, we may still need to
>>> copy hints explicity in planner rules, if we want to keep the hint, which
>>> is burdensome.
>>>
>>> - Haisheng
>>>
>>>
ch concept, we may still need to
> > copy hints explicity in planner rules, if we want to keep the hint, which
> > is burdensome.
> >
> > - Haisheng
> >
> > --------------
> > 发件人：Danny Chan
> > 日 期：2019年10月1
still need to
> > copy hints explicity in planner rules, if we want to keep the hint, which
> > is burdensome.
> >
> > - Haisheng
> >
> > --------------
> > 发件人：Danny Chan
> > 日 期：2019年10月16日 14:54:46
&
ch is
> burdensome.
>
> - Haisheng
>
> --
> 发件人：Danny Chan
> 日 期：2019年10月16日 14:54:46
> 收件人：
> 主 题：Re: [DISCUSS] Support Sql Hint for Calcite
>
> Thanks for the clarification.
>
> I understand you worried. Yes, the effort/memory would
--
发件人：Danny Chan
日 期：2019年10月16日 14:54:46
收件人：
主 题：Re: [DISCUSS] Support Sql Hint for Calcite
Thanks for the clarification.
I understand you worried. Yes, the effort/memory would be wasted or meaningless
if hints are not used. This is just what a hint does, it is a “hint” and
non
Thanks for the clarification.
I understand you worried. Yes, the effort/memory would be wasted or meaningless
if hints are not used. This is just what a hint does, it is a “hint” and
non-mandatory, but we should give the chance to let user see them, it is the
use that decide if to use the
By “skeptical” I mean that I think we can come up with a mechanism to copy
hints when applying planner rules, but even when we have implemented that
mechanism there will be many cases where people want a hint and that hint is
not copied to the RelNode where it is needed, and many other cases
Thanks Julian
> I am skeptical that RelWithHint will work for large queries.
For “skeptical” do you mean how to transfer the hints during rule planning ?
I’m also not that confident yet.
> How do we introduce it in a reversible way
Do you mean transform the RelWithHint back into the SqlHint ?
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 wrote:
>
> Hi, Julian, do you think we can make some effort to push this feature into
> release 1.22 ? The Flink
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
Vladimir, really thanks for providing these practical hints.
I’m not planning to add any hints implementation in the first PR, I just want
to add a framework to let us add a hint implementation conveniently. I would
very appreciate for it if you can give some suggestions to make the framework
Frankly speaking I would refrain from adding `table WITH ...`
It is not clear if you allow to add hints at subquery level. I think we
should allow that.
For instance, https://github.com/ossc-db/pg_hint_plan allows top-level
hints only, and that is really hard to use when SQL is build dynamically.
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
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
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
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
20 matches
Mail list logo
