[
https://issues.apache.org/jira/browse/CALCITE-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17003800#comment-17003800
]
Rui Wang commented on CALCITE-3638:
-----------------------------------
Actually after a second thought, if Calcite does not want to have a limitation
on what hints should be allowed, option 2 is better as it will be left engine
to decide what hints they will define, which is a much more extensible
approach.
> Reduce ambiguous hint strategies
> --------------------------------
>
> Key: CALCITE-3638
> URL: https://issues.apache.org/jira/browse/CALCITE-3638
> Project: Calcite
> Issue Type: Sub-task
> Reporter: Rui Wang
> Assignee: Rui Wang
> Priority: Major
>
> Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT
> /*hints*/. Also, hints are designed to be propagable such that the top SELECT
> hints can be propagated to other hintable nodes.
> For some hint strategies like resource, there will be ambiguity because we
> allow it be applicate to more than one type of node (e.g. resource works for
> both project and aggregate).
> So we could:
> 1. want to set resources for project
> 2. want to set resources for aggregate
> 3. want to set resources for project and aggregate, but have different
> parameters.
> There are two alternatives:
> 1. don't limit hint syntax to the top select. Allow it be put near, e.g.
> aggregation, etc.
> 2. have different names for the resource hint. e.g. project_resources,
> aggregate_resources, etc.
> I personally prefer option 1, as it will reduce ambiguity from the root.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
