Yes, you have to go with JOIN and create better index for your query. Sergi
2017-05-03 16:27 GMT+03:00 kmandalas <[email protected]>: > @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. >
