[
https://issues.apache.org/jira/browse/SOLR-10273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928044#comment-15928044
]
David Smiley commented on SOLR-10273:
-------------------------------------
Thanks for the pointer [~mikemccand]! Wow... it seems index/merge performance
could vary quite a bit based on something that seems to me very fragile (not
considering large/small fields here; just in general). Why doesn't Lucene sort
the FieldInfos such that the field number ascends as the field name
alphabetically ascends? I can file an issue if you think that would be a net
benefit. Even with that, it's a shame a bulk merge can't happen if some fields
simply aren't present in some segments yet are in others. Perhaps again,
Lucene could be improved to look across the segments and add all FieldInfo(s)
to the segment being written that are in others but not the current one?
Perhaps not if doing so would add > X FieldInfos. I have not looked at this
part of Lucene in-depth. I suspect that the reason these ideas have yet to be
implemented may be because FieldInfo(s) need to be generated in advance of
knowing all those that may need to exist.
> 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]