[
https://issues.apache.org/jira/browse/SOLR-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Takahiro Ishikawa updated SOLR-9612:
------------------------------------
Attachment: SOLR-9612.patch
updated
> 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: [email protected]
For additional commands, e-mail: [email protected]
