@Andrey: there is reason that I have selected REPLICATED over PARTITIONED cache due to my business case. Custom Affinity is under investigation, however seems over complicated for my scenario for starters. Now, even if PARTITIONED is used and things get done in parallel, the Network I/O is involved when reducing the results and in my case I get back rows with many columns and not a couple of SUM or AVG
@Sergi: My query has an IN clause. At the following link https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations <https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations> is mentiond that: /If the query contains an IN operator, there can be two issues: First, it is impossible to provide a variable list of parameters. That means that you have to specify the exact list in the query, for example, where id in (?, ?, ?). You cannot write - where id in ? and pass an array or collection. Second, this query will not use indexes. / So, let's say I create a grouped Index. Will it cover me from the case above? Or I will have to go with JOIN? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-SQL-Indexing-Performance-problems-tp12342p12391.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
