[
https://issues.apache.org/jira/browse/SOLR-10273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927405#comment-15927405
]
David Smiley commented on SOLR-10273:
-------------------------------------
[~mikemccand] might you know what Rob is referring to? I'd like to see where
this happens in Lucene so I can learn more about it. I've been looking around
a bit, like in SegmentMerger.
If there's really an issue here, I could modify the patch to ignore field sizes
and instead look for only the fields declared as "large" (SOLR-10286).
> Re-order largest field values last in Lucene Document
> -----------------------------------------------------
>
> Key: SOLR-10273
> URL: https://issues.apache.org/jira/browse/SOLR-10273
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 6.5
>
> Attachments: SOLR_10273_DocumentBuilder_move_longest_to_last.patch
>
>
> (part of umbrella issue SOLR-10117)
> In Solr's {{DocumentBuilder}}, at the very end, we should move the field
> value(s) associated with the largest field (assuming "stored") to be last.
> Lucene's default stored value codec can avoid reading and decompressing the
> last field value when it's not requested. (As of LUCENE-6898).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]