[
https://issues.apache.org/jira/browse/IGNITE-14699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-14699:
-----------------------------------
Labels: IEP-71 important ise (was: IEP-71 important)
> Provide Index Queries API
> -------------------------
>
> Key: IGNITE-14699
> URL: https://issues.apache.org/jira/browse/IGNITE-14699
> Project: Ignite
> Issue Type: New Feature
> Reporter: Maksim Timonin
> Assignee: Maksim Timonin
> Priority: Major
> Labels: IEP-71, important, ise
> Fix For: 2.12
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Phase 1 from:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search]
> Some notes about implementation:
> 1. MergeSort reducer of index queries isn't part of this ticket. So this
> ticket should provide queries for operations: lt, gt, lte, gte, between. See
> IGNITE-14703.
> 2. There is no lock on Index in moment of querying. So concurrent operations
> on index can affect result of query. SQL also doesn't lock index.
> 3. QueryParallelism doesn't affects IndexQuery. IndexQuery reuse
> infrastructure of CacheQuery, and it doesn't use info about segments. It
> should be done in a separate ticket, providing parallelism by segments.
> Currently we initialize cursor over segments within same thread sequentially.
> Segments initialization is fast operation, so there is no much overhead.
> 4. By the same reason IndexQuery fetches index lazy. SQL fetches index when
> query is initialized, after that user iterates over prepared result.
> IndexQuery doesn't prepare result. In case of multiple segments, it will slow
> down IndexQuery while parallelism isn't implemented. From other side, it make
> result more sensitive for concurrent operations on an index.
>
> After implementing query parallelism, we can will 3rd issue. 4th should be
> discussed after that, after some performance testing.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
