Skip to content

Conversation

@HiDAl
Copy link

@HiDAl HiDAl commented Jul 12, 2023

As per #97222, the calculation of IndicesQueryCache is computationally expensive due to some internal loops. Reading the current code, it'd be hard to simplify the calculation, without a big refactor. This is a sad and hacky attempt to give a solution to the current situation (Draft PR 😉), so users won't be affected by this O(n^2) loop.

In strange case that this solution suffices in the short term, we can apply the same idea to the following classes, which are still using the old approach TransportClusterStatsAction.java & TransportClusterStatsAction.java Last night, in a dream, I came up with his memoized solution, which I applied to these 2 classes.

closes #97222

@HiDAl HiDAl added >bug :Data Management/Stats Statistics tracking and retrieval APIs Team:Data Management Meta label for data/management team v8.10.0 labels Jul 12, 2023
@elasticsearchmachine
Copy link
Collaborator

Hi @HiDAl, I've created a changelog YAML for you.

@nielsbauman
Copy link
Contributor

Closing this due to staleness and a more recent PR being opened: #130857.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>bug :Data Management/Stats Statistics tracking and retrieval APIs Team:Data Management Meta label for data/management team v9.2.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Computing IndicesQueryCache stats is O(N²) in shard count

8 participants