You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding a range query means that indices can get skipped based on their min/max values. A terms query by itself is not enough to trigger this optimisation.
I've seen situations in our test environments where some searches without a range filter are inexplicably slow. One example is the service map search where we walk traces. We only have a terms query on trace.id there. My only theory is that sometimes shards are very slow to respond even though they don't have any data matching the search. We should identify searches without range filters and add them where possible.
The text was updated successfully, but these errors were encountered:
Adding a range query means that indices can get skipped based on their min/max values. A terms query by itself is not enough to trigger this optimisation.
I've seen situations in our test environments where some searches without a range filter are inexplicably slow. One example is the service map search where we walk traces. We only have a terms query on trace.id there. My only theory is that sometimes shards are very slow to respond even though they don't have any data matching the search. We should identify searches without range filters and add them where possible.
The text was updated successfully, but these errors were encountered: