You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Ishan Chattopadhyaya (JIRA)" <ji...@apache.org> on 2017/03/13 16:49:42 UTC
[jira] [Commented] (SOLR-9612) Stored field access should be
avoided when it's not needed
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org