One more thing - it's not necessary for Ignite to send the query for all
server nodes, if it's possible to understand from the query, on which node
all data is placed(i.e. it filters by affinity key), it will send this
query only to the needed node.

Evgenii

2018-05-21 11:25 GMT+03:00 Evgenii Zhuravlev <e.zhuravlev...@gmail.com>:

> Hey,
>
> It's configurable by using property queryParallelism and by default, an
> SQL query is executed in a single thread on each participating Ignite node.
> Please refer this documentation for additional information:
>
> https://apacheignite-sql.readme.io/docs/performance-
> and-debugging#section-query-parallelism
>
> Evgenii
>
> 2018-05-18 2:56 GMT+03:00 Sanjeev <gupta...@gmail.com>:
>
>> Hi,
>>
>> I would like to understand how SQL queries are executed on Ignite Server
>> Nodes. Each Ignite Server Node has some number of primary partitions it is
>> responsible for. When a query is sent, let' say through JDBC interface,
>> this
>> query is routed to all the server nodes where data resides. So the
>> question
>> is, if a server node has 5 primary partitions it is responsible for, does
>> the server node spawn multiple threads and process these partitions
>> concurrently, or does it use a single thread, and process partitions 1 by
>> 1,
>> keeping temporary results in memory.
>>
>> If it does process partitions concurrently on a single node, another
>> question is, if there are more number of partitions than available cores,
>> is
>> it smart enough to grab all available cores, and then cycle through all
>> partitions in chunks of available cores keeping temporary results in
>> memory
>> and merging them as needed.
>>
>> I am trying to get a sense of the SQL query processing engine and its
>> internals especially within a single server node.
>>
>> Thanks...
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>
>

Reply via email to