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 wit
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
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，Julia
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.
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
m
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 m
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 commu
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
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 whe
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 hints
hint, which 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/mem
t, 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月16日 14:
such 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
> > 日 期
anner, there 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
>>>
>>> ---
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,
> > > > > 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 expression
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 pla
; > > > > > >
> > > > > > > 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
- 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 be wasted or meaningless
if hints are not used. This is just what a hint does, it is a “hint
19 matches
Mail list logo
