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

Keith Laban commented on SOLR-8220:
-----------------------------------

Thanks [~ichattopadhyaya], this is my first time submitting a patch. This was 
originally done against 5.3.1 in the future i'll submit it based on trunk. 

I also noticed that there is a bug in the patch I submited. 

The line which reads 
{code}
if(null == sf){
  return doc;
}
{code}

should be
{code}
if(null == sf){
  continue;
}
{code}

[~ysee...@gmail.com] I think that we definitely need something like that. 
Currently CompressingStoredFieldsReader.visitDocument needs to visit the whole 
document in stored field to know which fields there are. Ideally we would 1) be 
able to avoid doing any work in stored fields if they can instead by read out 
of docValues. 2) have a mechanism for LazyDocument to know to read the lazy 
field from docValues instead of from stored fields. 3) know about values which 
aren't stored but should be read from docValues.

> Read field from docValues for non stored fields
> -----------------------------------------------
>
>                 Key: SOLR-8220
>                 URL: https://issues.apache.org/jira/browse/SOLR-8220
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Keith Laban
>         Attachments: SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>    -- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to