...

1. Query arguments are applied on the client. 
2. Target node is determined from the list of partitions. We assume that partition distribution for the given affinity topology versions has been requested in advance similarly how we do that for C++ thin client. 
3. If only one node is resolved, send request to it. If several nodes are resolved - send request to random node from the list. 
4. Request is executed on the server and current affinity topology version is attached to the response. If it differs from the one received from the client, new partition tree is built and attached.
5. Client checks if current affinity topology version differs. If yes - old partition tree is invalidated.

Optimizations

If partition tree is extracted form the query successfully, then two types of optimizations are possible:

1. If tree evaluation returned empty partition set, return empty result set immediately without actual query execution
2. If tree evaluation returned one partition, then all data reside on a single node. Convert query to "local" and execute it on target node without two-phase flow
3. If tree evaluation returned several partitions, and all of them appear to be on the same node, then try to execute query speculatively on a single node, provided that partitions are still on that node. Fallback to normal execution mode in case of concurrent eviction.

Management and Monitoring

It is very important to let user know if partition pruning is applicable to query for performance tuning. For every cached two-step query we may expose the following information:

1. Whether partition pruning is applicable
2. Formatted partition tree
3. Affinity topology version of the plan
4. If not applicable - explain why (e.g. non-equi join, incompatible affinity functions, etc.)

 Also we need to let user disable this optimization. Otherwise a bug in implementation may lead to incorrect results with no workarounds. System on configuration property could be used for that.

Tickets