Performance impact of track_scores

Describe the issue:
I’ve run into some unexpected behavior when using the track_scores option in queries.

When I run a query for a single term that returns a large number of hits, setting track_scores=true increases the query time as reported by OpenSearch (took). Since it’s a single term query, the scores are all the same, but I guess increased execution time is to be expected for keeping track of more things.

However, when I query for a large number of terms, the effect is reversed. Setting track_scores=true makes the query execute faster! This seems counter-intuitive as I wouldn’t expect additional tracking to improve performance. At best I would have expected it to have no impact at all.

I tested this via the OpenSearch dashboard as well as through the java client. For an index with 162 million docs on two shards, tracking scores reduced the query time by about 20%. Tried other test setups as well and the effect was noticeable as well.

Is there any insight into why this might happen? I’m trying to optimize my queries/mappings and some info on this would be useful.

Versions : 1.0

Sample query:

            ...insert 100 values here

Hi @front ,

Indeed the track_scores may have significant performance overhead [1], but the results you are seeing are surprising. May I ask you please to share the search hit stats w/o track_scores: the time it took, number of results returned, etc. Thank you.

[1] Remove support for `track_scores` · Issue #32982 · elastic/elasticsearch · GitHub

I played around a bit more and here are the results.
The query is as shown above, a terms query with 100 values and a sort field , but with an added size:500. The query itself shows ~15 million hits when track_total_hits is enabled. The query filters are the same, so all tests have the same hits/results, but the took time varies depending on the options used:

track_scores    track_total_hits   took
-               -                  690
true            -                  510
-               true               350
true            true               510

So it seems both options, even individually, reduce the execution time, when I thought it would be the opposite.