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

Ishan Chattopadhyaya commented on SOLR-9612:
--------------------------------------------

Moving to 6.5, since 6.4 has already been released.

> 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.5, 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.15#6346)

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

Reply via email to