Change index.mapping.use_doc_values_skipper default setting to true
#134221
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
Collaborator
|
Hi @romseygeek, I've created a changelog YAML for you. |
martijnvg
approved these changes
Sep 5, 2025
Member
martijnvg
left a comment
martijnvg
left a comment
There was a problem hiding this comment.
Thanks Alan, LGTM!
I think doc value skippers will now also be enabled for _tsid field? (in snapshot versions) (If I understand TimeSeriesIdFieldMapper#getInstance(...) correctly)
docs/changelog/134221.yaml
Outdated
| @@ -0,0 +1,5 @@ | |||
| pr: 134221 | |||
Member
There was a problem hiding this comment.
Let's label this as a non-issue? Because released versions will not run with doc value skippers enabled And when the feature flag gets removed then we label it as a feature or enhancement.
Contributor
Author
Yes, that looks right. It doesn't remove the backing index for this field though, it only enables the skipper. |
Member
Yes, the |
…ers' into benchmark/main-enabled-skippers
romseygeek
commented
Sep 8, 2025
| assertThat(dataProfiles, hasSize(1)); | ||
| List<OperatorStatus> ops = dataProfiles.get(0).operators(); | ||
| assertThat(ops, hasSize(5)); | ||
| assertThat(ops, hasSize(6)); |
Contributor
Author
There was a problem hiding this comment.
This change adds an extra ValuesSourceReaderOperator step into this ESQL query - does that sound right to you @martijnvg ?
Member
There was a problem hiding this comment.
Do you know for what field(s) both value source reader operations are?
Contributor
Author
There was a problem hiding this comment.
The new one is for @timestamp:
{"operator":"ValuesSourceReaderOperator[fields = [@timestamp]]","status":{"readers_built":{"@timestamp:column_at_a_time:BlockDocValuesReader.SingletonLongs":3},"values_loaded":98,"process_nanos":887208,"pages_received":3,"pages_emitted":3,"rows_received":98,"rows_emitted":98}}
The other is for _tsid, cpu and cluster and is unchanged from before:
{"operator":"ValuesSourceReaderOperator[fields = [_tsid, cpu, cluster]]","status":{"readers_built":{"_tsid:column_at_a_time:BlockDocValuesReader.SingletonOrdinals":3,"cluster:column_at_a_time:BlockDocValuesReader.SingletonOrdinals":3,"cpu:column_at_a_time:BlockDocValuesReader.SingletonDoubles":3},"values_loaded":294,"process_nanos":1226959,"pages_received":3,"pages_emitted":3,"rows_received":98,"rows_emitted":98}}
Member
There was a problem hiding this comment.
Can you check whether the LuceneSourceOperator pushes down the buckets as filters? For example do see IndexOrDocValuesQuery(indexQuery=@timestamp:[1713139320000 TO 1713139379999], dvQuery=@timestamp:[1713139320000 TO 1713139379999]) in processedQueries of the status of LuceneSourceOperator?
Maybe this change results in compute engine no longer pushing down filters?
Member
There was a problem hiding this comment.
With this change, the field caps api for @timestamp field will no longer return that it is indexed and that is why I think the query plan is different, with this as a result.
I don't think this blocks merging this pr. Maybe we need to think about marking a field as indexed if it has doc value skippers and is part of index sorting before we release the feature flag?
Member
There was a problem hiding this comment.
I checked LuceneSourceOperator with this change and there aren't any IndexOrDocValuesQuery instances in processed query.
So I think this is good. Let's merge it when CI is green.
…ers' into benchmark/main-enabled-skippers
Contributor
Author
|
Buildkite benchmark this with tsdb please |
Contributor
Author
|
Trying a benchmark again after I've merged in |
Contributor
Author
|
Buildkite benchmark this with elastic-logs-logsdb please |
Collaborator
💚 Build Succeeded
This build ran two elastic-logs-logsdb benchmarks to evaluate performance impact of this PR. History
cc @romseygeek |
Contributor
Author
|
TSDB benchmark comparison: 12% reduction in index size, and between 10-50% penalty on query performance. The odd one is the throughput on 12% is a nice reduction but I do wonder if we would actually get better bang for our buck by looking at other fields. The |
Member
We chatted about this field before and looks like this field should no have a points index to begin with for the reason you mentioned. In order to achieve this, our builtin stack templates should map this with |
Member
|
I also wonder how much here is noise. If I look at |
Member
|
Some things I'd like to note:
|
…ers' into benchmark/main-enabled-skippers
Member
|
I ran the TSDB metricsgen track and got encouraging results. The highlights are:
Some more details on the benchmark:
Click to expand full rally compare... |
Contributor
Author
|
Very encouraging! The much smaller time range buckets being slower is expected I guess, as they won't be able to make use of the sparse indexes as efficiently as larger ranges. @martijnvg @kkrik-es I think this performance is close enough for us to merge and see if we can improve the small time range buckets performance in follow-ups. WDYT? |
Contributor
Indeed, very promising! Let's get it in, behind a feature flag, to further assess without affecting serverless. |
martijnvg
approved these changes
Oct 21, 2025
Member
martijnvg
left a comment
martijnvg
left a comment
There was a problem hiding this comment.
🚢
The index.mapping.use_doc_values_skipper index setting only has effect today if doc_values_skipper feature flag is enabled. So PR as is, is good!
romseygeek
changed the title
@timestamp and host.name fields in LogsDBindex.mapping.use_doc_values_skipper default setting to true
chrisparrinello
pushed a commit
to chrisparrinello/elasticsearch
that referenced
this pull request
Oct 24, 2025
…e` (elastic#134221) TSBD and LogsDB indexes with this setting set to true do not use backing indexes for `host.name`, `_tsid` or `@timestamp` fields, and instead enable sparse indexes on their doc_values fields. This was originally added and set to default to `true` a while back, but was then changed to default to `false` when performance suffered. Changes to lucene, and the addition of filter-by-filter optimizations on skipper queries, means that performance looks more acceptable now. This is still gated behind a feature flag so that we can measure the behaviour in nightly benchmarks before enabling for public use.
fzowl
pushed a commit
to voyage-ai/elasticsearch
that referenced
this pull request
Nov 3, 2025
…e` (elastic#134221) TSBD and LogsDB indexes with this setting set to true do not use backing indexes for `host.name`, `_tsid` or `@timestamp` fields, and instead enable sparse indexes on their doc_values fields. This was originally added and set to default to `true` a while back, but was then changed to default to `false` when performance suffered. Changes to lucene, and the addition of filter-by-filter optimizations on skipper queries, means that performance looks more acceptable now. This is still gated behind a feature flag so that we can measure the behaviour in nightly benchmarks before enabling for public use.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TSBD and LogsDB indexes with this setting set to
truedo not use backing indexesfor
host.name,_tsidor@timestampfields, and instead enable sparse indexeson their doc_values fields.
This was originally added and set to
truea while back, but was then changed tofalsewhen performance suffered. Changes to lucene, and the addition of filter-by-filteroptimizations on skipper queries, means that performance looks more acceptable now.
This is still gated behind a feature flag so that we can measure the behaviour in nightly
benchmarks before enabling for public use.