[ 
https://issues.apache.org/jira/browse/SOLR-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869727#comment-17869727
 ] 

David Smiley commented on SOLR-10255:
-------------------------------------

IMO it doesn't make sense for such a field to be stored & docValues, so I'd say 
"no" to enable docValues by default on BinaryField.  The new docValues default 
of true only makes sense on "short" fields.  BinaryField generally doesn't 
apply.

> Large psuedo-stored fields via BinaryDocValuesField
> ---------------------------------------------------
>
>                 Key: SOLR-10255
>                 URL: https://issues.apache.org/jira/browse/SOLR-10255
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 9.7
>
>         Attachments: SOLR-10255.patch, SOLR-10255.patch
>
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> (sub-issue of SOLR-10117)  This is a proposal for a better way for Solr to 
> handle "large" text fields.  Large docs that are in Lucene StoredFields slow 
> requests that don't involve access to such fields.  This is fundamental to 
> the fact that StoredFields are row-stored.  Worse, the Solr documentCache 
> will wind up holding onto massive Strings.  While the latter could be tackled 
> on it's own somehow as it's the most serious issue, nevertheless it seems 
> wrong that such large fields are in row-stored storage to begin with.  After 
> all, relational DBs seemed to have figured this out and put CLOBs/BLOBs in a 
> separate place.  Here, we do similarly by using, Lucene 
> {{BinaryDocValuesField}}.  BDVF isn't well known in the DocValues family as 
> it's not for typical DocValues purposes like sorting/faceting etc.  The 
> default DocValuesFormat doesn't compress these but we could write one that 
> does.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to