[
https://issues.apache.org/jira/browse/IGNITE-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6624:
------------------------------------
Description:
We need to filter backup keys during query execution. Currently to achieve this
we do the following:
1) Get row link
2) Materialize the row (!!!)
3) Create H2 row (H2 wrapping)
4) Then get key from H2 row (unwrapping)
5) Calculate partition through affinity function
What it might look like:
1) Get row link
2) Get partition from link
This ticket is to implement working with partitions rather than keys when
possible,
was:
We need to filter backup keys during query execution. Currently to achieve this
we do the following:
1) Get row link
2) Materialize the row (!!!)
3) Create H2 row (H2 wrapping)
4) Then get key from H2 row (unwrapping)
5) Calculate partition through affinity function
What it might look like:
1) Get row link
2) Get partition from link
p.1 is very simple to implement. p.2 might be harded and probably should be
implemented out of scope of this ticket.
> SQL: IndexingQueryCacheFilter should use immediate partition data if possible
> -----------------------------------------------------------------------------
>
> Key: IGNITE-6624
> URL: https://issues.apache.org/jira/browse/IGNITE-6624
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
> Reporter: Vladimir Ozerov
> Assignee: Vladimir Ozerov
> Labels: performance
> Fix For: 2.4
>
>
> We need to filter backup keys during query execution. Currently to achieve
> this we do the following:
> 1) Get row link
> 2) Materialize the row (!!!)
> 3) Create H2 row (H2 wrapping)
> 4) Then get key from H2 row (unwrapping)
> 5) Calculate partition through affinity function
> What it might look like:
> 1) Get row link
> 2) Get partition from link
> This ticket is to implement working with partitions rather than keys when
> possible,
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
