Please follow the instructions here to unsubscribe. Note, you _MUST_ use the exact same e-mail you subscribed with.
See the "unsubscribe" link here: http://lucene.apache.org/solr/resources.html If you have problems, have you tried to follow the instructions here? https://wiki.apache.org/solr/Unsubscribing%20from%20mailing%20lists Best, Erick On Wed, Dec 2, 2015 at 5:55 PM, Johny John <phpjo...@outlook.com> wrote: > dev-unsubscr...@lucene.apache.org > > Sent from Windows Mail > > From: Keith Laban (JIRA) > Sent: Thursday, December 3, 2015 6:19 AM > To: dev@lucene.apache.org > > > [ > https://issues.apache.org/jira/browse/SOLR-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036972#comment-15036972 > ] > > Keith Laban commented on SOLR-8220: > ----------------------------------- > > My only concern is that we may have to add a flag for this and for whatever > we decide in SOLR-8344 which is just going to add to he confusion. Thoughts? > >> Read field from docValues for non stored fields >> ----------------------------------------------- >> >> Key: SOLR-8220 >> URL: https://issues.apache.org/jira/browse/SOLR-8220 >> Project: Solr >> Issue Type: Improvement >> Reporter: Keith Laban >> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, >> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, >> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, >> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, >> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, >> SOLR-8220.patch >> >> >> Many times a value will be both stored="true" and docValues="true" which >> requires redundant data to be stored on disk. Since reading from docValues >> is both efficient and a common practice (facets, analytics, streaming, etc), >> reading values from docValues when a stored version of the field does not >> exist would be a valuable disk usage optimization. >> The only caveat with this that I can see would be for multiValued fields >> as they would always be returned sorted in the docValues approach. I believe >> this is a fair compromise. >> I've done a rough implementation for this as a field transform, but I >> think it should live closer to where stored fields are loaded in the >> SolrIndexSearcher. >> Two open questions/observations: >> 1) There doesn't seem to be a standard way to read values for docValues, >> facets, analytics, streaming, etc, all seem to be doing their own ways, >> perhaps some of this logic should be centralized. >> 2) What will the API behavior be? (Below is my proposed implementation) >> Parameters for fl: >> - fl="docValueField" >> -- return field from docValue if the field is not stored and in >> docValues, if the field is stored return it from stored fields >> - fl="*" >> -- return only stored fields >> - fl="+" >> -- return stored fields and docValue fields >> 2a - would be easiest implementation and might be sufficient for a first >> pass. 2b - is current behavior > > > > -- > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
