[
https://issues.apache.org/jira/browse/IGNITE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749729#comment-16749729
]
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=2871261&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)