Yep, just create a separate index. (I saw in your other messages that you’re already trying that)
Stan From: eugene miretsky Sent: 18 сентября 2018 г. 17:56 To: user@ignite.apache.org Subject: Re: IGNITE-8386 question (composite pKeys) So how should we work around it now? Just create a new index for (customer_id, date)? Cheers, Eugene On Mon, Sep 17, 2018 at 10:52 AM Stanislav Lukyanov <stanlukya...@gmail.com> wrote: Hi, The thing is that the PK index is currently created roughly as CREATE INDEX T(_key) and not CREATE INDEX T(customer_id, date). You can’t use the _key column in the WHERE clause directly, so the query optimizer can’t use the index. After the IGNITE-8386 is fixed the index will be created as a multi-column index, and will behave the way you expect (e.g. it will be used instead of the affinity key index). Stan From: eugene miretsky Sent: 12 сентября 2018 г. 23:45 To: user@ignite.apache.org Subject: IGNITE-8386 question (composite pKeys) Hi, A question regarding https://issues.apache.org/jira/browse/IGNITE-8386?focusedCommentId=16511394&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16511394 It states that a pkey index with a compoise pKey is "effectively useless". Could you please explain why is that? We have a pKey that we are using as an index. Also, on our pKey is (customer_id, date) and affinity column is customer_id. I have noticed that most queries use AFFINITY_KEY index. Looking at the source code, AFFINITY_KEY index should not even be created since the first field of the pKey is the affinity key. Any idea what may be happening? Cheers, Eugene
