You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

IDIEP-24
AuthorVladimir Ozerov Ozerov
SponsorVladimir Ozerov Ozerov
Created19 Jun 2018
StatusDRAFT


Motivation

SQL query may scan arbitrary set of cache values. In general case interested values may reside on every cluster node, so broadcast is needed. What is worse, when distributed joins are enabled, another broadcast for every broadcasted message may be needed. One of the most important optimization techniques is so-called "partition pruning", allowing to calculate a set of partitions and nodes which will return empty result without actual query execution. Query parts are not executed on these nodes, increasing overall system throughput and providing nearly linear scaling. 

Recent researches in distributed query processing assume that CPU is relatively cheap resource, while network IO and disk IO are equally costly operations. Partition pruning not only saves network requests, but also avoids unnecessary executionы of local query parts, preventing page cache trashing and additional disk reads (mostly random).

Thus, partition pruning is a critical optimization technique for both distributed and local queries and should be treated as high priority task for Ignite SQL engine.

Competitive Analysis

This technique is used excessively by both distributed databases and classical RDBMS vendors (as a part of their partitioning/sharding solutions). 

Proposed Changes

TODO

Tickets

key summary type created updated due assignee reporter priority status resolution

JQL and issue key arguments for this macro require at least one Jira application link to be configured

  • No labels