[
https://issues.apache.org/jira/browse/SOLR-10273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15925532#comment-15925532
]
David Smiley commented on SOLR-10273:
-------------------------------------
Thanks for alerting me to this Rob! Is there a size threshold at which you
think it's not a de-optimization -- perhaps the 16KB mark? I suppose your
point is consistency... so if we _always_ move the values for certain fields
last then there's no problem?
bq. Also bulk merging relies upon field number consistency across segments
Can you point me to a line of code in CompressingStoredFieldsWriter that is
pertinent? I don't see it.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
