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 <[email protected]> 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 <[email protected]> > *Sent: *12 сентября 2018 г. 23:45 > *To: *[email protected] > *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 > > >
