[
https://issues.apache.org/jira/browse/IGNITE-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15812730#comment-15812730
]
Dmitriy Setrakyan commented on IGNITE-4517:
-------------------------------------------
I think this is a very questionable feature. We already plan support for
sending a query to a right partition in IGNITE-4510, which should be enough.
Don't think we need anything beyond that.
> Add ability to execute SQL queries on certain partition(s)
> ----------------------------------------------------------
>
> Key: IGNITE-4517
> URL: https://issues.apache.org/jira/browse/IGNITE-4517
> Project: Ignite
> Issue Type: Task
> Components: SQL
> Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Motivation*
> This could be useful for certain cases:
> 1) Simple queries where partition can be determined easily in advance, either
> automatically (IGNITE-4509, IGNITE-4510), or manually.
> 2) Spark data frame integration (IGNITE-3084)
> *Proposed API*
> class Query {
> int[] partitions();
> void partitions(int...);
> }
> Important points:
> 1) Partitions are defined in the very base {{Query}} class because we already
> has this feature for {{ScanQuery}} and potentially any query type can benefit
> from it. If query doesn't support partitions, exception should be thrown.
> 2) User should be able to specify multiple partitions, not only one. This
> will make our API more flexible for 3-rd party integrations like Spark. Also
> it will help users with fine-grained tuning. E.g. if user has a query {{...
> WHERE attribute IN (?, ?, ...)}}, he can determine partitions for {{IN}}
> arguments in advance.
> Probably this feature should not be supported for distributed joins. On the
> other hand - why not? Query is always created from some cache, so the first
> map step can be executed only against target partitions, and the rest
> execution flow can go through all partitions of other caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
