[
https://issues.apache.org/jira/browse/CALCITE-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang updated CALCITE-3638:
------------------------------
Description:
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.
was:
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.
> 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)
