[ 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)