[jira] [Updated] (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:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-9612: --- Fix Version/s: (was: 6.4) 6.5 > 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
[jira] [Updated] (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: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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
