Ignite select queries (including nested select) on replicated caches - What if any processing happens on the query initiator?

Question

Few questions,

1. For select queries on replicated caches is it true that NO processing happens on the query initiator (say in an ignite client node when querying from application in the case of application embedded ignite client). including when selecting only a subset of the 'fields/columns' and 'entries/rows' from a cache?
2. In the case of nested select queries all involving replicated caches (either a select nested in a select or a select nested in an insert where some aggregation is done on the nested selected data before insert) is it still true that NO processing happens on the query initiator?
3. If 1 & 2 is true is it still true even when this is performed using ignite spring data abstraction (with @query annotation)?

Thanks

lmk

CLARIFICATION UPDATE (June 17th, 2020):

Specifically, what processing can we not avoid on the client?. Reason i ask is for example in the second case i mentioned above i want to see what is the exact network & client (when query initiator is a client in this case) overhead when executing nested select queries all involving replicated caches particularly if they act over large rows/entities or perform computationally intensive operations repeatedly.

Answer 1

An SQL query is executed in a map-reduce fashion, in general, the reduce phase does happen on a query initiator that might be a client or a server node. Replicated caches help you to perform the whole execution on a single node, but can't avoid any processing on a client since it can't store the data.

Could you please explain, why is it important for you/are there any issues with it?