[
https://issues.apache.org/jira/browse/IGNITE-18691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-18691:
--------------------------------------
Description:
When we mapping a query, we need to know who is the primary replica for each
partition.
Current implementation based on storing such leaders into an "ordered" list.
The element number in which corresponds to the partition number.
InternalTable has several methods to get current assignments (see
{{InternalTable#assignments}} and {{InternalTable#primaryReplicas}}).
Currently each of them explicitly sort result using partition numbers.
This looks not optimal, since we call "assignments" for each table during
preparing a single query.
One possible solution is to simply change the type of paritionMap inside
InternalTableImpl to some kind of sorted implementation, but the disadvantages
of this change should be carefully investigated.
was:
When we mapping a query, we need to know who is the primary replica for each
partition.
Current implementation based on storing such leaders into an "ordered" list.
The element number in which corresponds to the partition number.
InternalTable has several methods to get current assignments (see
{{InternalTable#assignments}} and {{InternalTable#primaryReplicas}}).
Currently each of them explicitly sort result using partition numbers.
This looks not optimal, since we call "assignments" for each table during
preparing a single query.
One possible solution is to simply change the type of paritionMap inside
InternalTableImpl to some kind of sorted implementation, but the disadvantages
of this change should be carefully considered.
> Sql. Reduce overhead of sorting assignments.
> --------------------------------------------
>
> Key: IGNITE-18691
> URL: https://issues.apache.org/jira/browse/IGNITE-18691
> Project: Ignite
> Issue Type: Task
> Components: sql
> Reporter: Pavel Pereslegin
> Priority: Major
> Labels: ignite-3
>
> When we mapping a query, we need to know who is the primary replica for each
> partition.
> Current implementation based on storing such leaders into an "ordered" list.
> The element number in which corresponds to the partition number.
> InternalTable has several methods to get current assignments (see
> {{InternalTable#assignments}} and {{InternalTable#primaryReplicas}}).
> Currently each of them explicitly sort result using partition numbers.
> This looks not optimal, since we call "assignments" for each table during
> preparing a single query.
> One possible solution is to simply change the type of paritionMap inside
> InternalTableImpl to some kind of sorted implementation, but the
> disadvantages of this change should be carefully investigated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
