Note the storage tradeoff of copy_to and how to avoid it - #7790
Open
ash9146 wants to merge 5 commits into
Open
Conversation
The 'Search as few fields as possible' section shows copy_to purely as a search-speed win, with no mention that the source fields (name, plot) remain separately indexed alongside the new combined field - meaning the example as written adds roughly a third field's worth of index storage rather than saving any. size-shards.md already frames copy_to as a way to reduce per-field mapping overhead, which only holds if indexing is disabled on the source fields once they're only needed via the combined field. This wasn't connected to the search-speed.md example, so readers following this guide as-is would not get that storage benefit and might be surprised by the added overhead. Added a note plus a cross-link to size-shards.md so readers see both the cost and the way to avoid it.
georgewallace
requested changes
Aug 5, 2026
georgewallace
left a comment
georgewallace
left a comment
Contributor
There was a problem hiding this comment.
We actually have a directive for notes so they render as such on the page, also made some suggestions to the verbiage.
…speed.md Co-authored-by: George Wallace <georgewallace@users.noreply.github.com>
Contributor
Elastic Docs AI PR menuCheck the box to run an AI review for this pull request.
Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team. |
Updated note formatting and clarified indexing advice.
georgewallace
approved these changes
Aug 5, 2026
georgewallace
left a comment
georgewallace
left a comment
Contributor
There was a problem hiding this comment.
LGTM, thanks for making the improvements
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Summary
The "Search as few fields as possible" section shows
copy_topurelyas a search-speed optimization, with no mention that the source fields
(
name,plot) remain separately indexed alongside the new combinedfield. As written, the example adds roughly a third field's worth of
index storage rather than saving any - this tradeoff wasn't documented
anywhere.
Context
size-shards.mdalready framescopy_toas a way to reduceper-field mapping overhead:
That framing only holds if indexing is disabled on the source fields
once they're only needed via the combined field (
"index": false).This connection wasn't made from
search-speed.md, so a readerfollowing this guide as-is would take on the storage overhead without
knowing there's a way to avoid it.
What's added
A short note right after the
copy_toexample that:nameandplotare still indexed individually inthis example, in addition to
name_and_plot"index": falseon the sourcefields, if they don't need to be searched individually)
size-shards.mdfor more detail oncopy_toas amapping-overhead reduction technique
Testing
copy_toexample and"Pre-index data"