trying to understand this: 1) In case where no indexes are involved and you are doing a table scan, it should automatically try to exploit available CPU cores and process each partition on a separate thread/core. At least table scan queries should entertain the idea dynamic parallelism through DML hints.
2) In case of indexes, what you are saying is that N trees are build for M primary partitions on a node, where N being degree of parallelism. So each tree is managing a certain number of partitions, M/N. As number of partition on a nodes increase or decrease, the N trees are adjusted to reflect that. What I am wondering is in case if indexes were created, then could we always create N trees. What are the performance implications of: 1) A single thread working on 1 large single index 2) A single thread working on 1 or few of the N small indexes based on the query. 3) N cores working on N small indexes in parallel. 3 should always perform well. Between 1 and 2, would one perform better or worse. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
