[ 
https://issues.apache.org/jira/browse/IGNITE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752024#comment-16752024
 ] 

Ignite TC Bot commented on IGNITE-10305:
----------------------------------------

{panel:title=--> Run :: All: No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2884340&buildTypeId=IgniteTests24Java8_RunAll]

> SQL: Optimize query execution if it targets only one or none partitions
> -----------------------------------------------------------------------
>
>                 Key: IGNITE-10305
>                 URL: https://issues.apache.org/jira/browse/IGNITE-10305
>             Project: Ignite
>          Issue Type: Task
>          Components: sql
>            Reporter: Vladimir Ozerov
>            Assignee: Alexander Lapin
>            Priority: Major
>              Labels: iep-24
>             Fix For: 2.8
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> This is a part of "Partition Pruning" IEP [1]. 
> Currently we try to extract partitions from map queries and route requests 
> accordingly. Several problems with this approach:
> 1) Individual map queries may target the same partition, but we never know 
> that, so we may want to setup a merge table when it is not really needed.
> 2) Sometimes query may reduce to no partitions. In this case we should not 
> execute anything at all and simply return empty result set.
> 3) If the whole query targets only one partition, we may skip the whole 
> splitter phase!
> I propose to do the following:
> # Try to extract partition from "original" query. 
> # If we see that exactly one partition is involved, then original query is a 
> map query, and reduce should be performed in "skip merge table" mode
> # If we see that there are no partitions because query is invalid (e.g. {{id 
> = 1 AND id = 2}}), then stop and return no results. This decision should be 
> cached in two-step plan.
> # If we see that there are some partitions, then we should apply arguments 
> and see the result. If result set is empty - return, but do not cache empty 
> result set decision, as it may change for another set of arguments.
> # If none of above hold, then do pushdowns and split, and analyze partitions 
> of individual map queries. For those of them where partition set is empty, we 
> should return empty result set without executing anything.
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to