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

Takahiro Ishikawa commented on SOLR-9612:
-----------------------------------------

No, this issue is different from SOLR-8220. This issue only focuses on 
performance but SOLR-8220 focuses on functionality.
SOLR-8220 enables to return field values from docValues, but always seek the 
fields from stored first.
My suggestion is when you know some fields are only from docValues, you don't 
need to seek the fields from stored and should skip.

"useDocValuesAsStored" is handled in getNonStoredDVs, and this issue doesn't 
intend to change the behavior.
See below how to handle "useDocValuesAsStored".
https://github.com/apache/lucene-solr/blob/branch_6_0/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L877-L886

> Stored field access should be avoided when it's not needed
> ----------------------------------------------------------
>
>                 Key: SOLR-9612
>                 URL: https://issues.apache.org/jira/browse/SOLR-9612
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Response Writers, search
>    Affects Versions: 6.0, 6.1, 6.2
>            Reporter: Takahiro Ishikawa
>            Priority: Minor
>              Labels: performance
>             Fix For: 6.3, master (7.0)
>
>         Attachments: SOLR-9612.patch
>
>
> This is a small enhancement. (unneeded stored access spend 5% in my profile 
> result)
> All fields which is written in fl parameter(some of them are only doc values 
> not stored) are iterated over from stored fields and it's inefficient. 
> Further when fl parameters are only docValues, we should avoid accessing 
> stored.
> I'm going to update a conservative patch.
> This patch exclude nonStoredDocValues fields from stored field list, and if 
> we don't need access stored, we skip it.
> What 'conservative' means is that when schema is dynamically changed this 
> patch not change behaviors.(ex. stored field 'a' is removed from schema, and 
> user search fl=a, then a is returned from DocStreamer.)
> But I'm not sure how should solr behaves when schema is dynamically changed.
> I think better approach is 
> Each fields are classified 3 types from schema and process each.
>  - stored                           -> fetch from stored
>  - nonStoredDocValues   -> fetch from docValues
>  - unknown                      -> error or lazy field(distinguishable?)
> But this might break backward compatibility.(like mentioned above)
> Any comments are welcome.



--
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