ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitriy Setrakyan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-4517) Add ability to execute SQL queries on certain partition(s)
Date Mon, 09 Jan 2017 20:15:58 GMT

    [ 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

> 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

View raw message