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

Uwe Schindler commented on SOLR-10816:
--------------------------------------

Hi Erick,
thanks for reminding me and thanks for fixing SOLR-12625.
I agree, the best would be to make the ID field stored and doc values enabled. 
This should be done anyways, as the ID field is most ofen of type "StrField", 
which has docvalues enabled by default for recent schema versions. But Maybe we 
should enforce some properties for "internal fields" like 'id', '_version' and 
similar.

> Change uniqueKey to use docValues and not stored field
> ------------------------------------------------------
>
>                 Key: SOLR-10816
>                 URL: https://issues.apache.org/jira/browse/SOLR-10816
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Varun Thacker
>            Priority: Major
>
> This issue is about the performance improvements you can get by avoiding 
> decompression during the first phase of a distributed search where only id 
> and score is needed.
> The improvements will be noticed for users if the docs are large or have lots 
> of fields in them. 
> For users who don't have this scenario it shouldn't slow things done by any 
> noticeable amounts?
> We should default the unique key field to use docValuues='true' and 
> stored='false' 
> Links to the discussion that lead to this idea:
> - 
> https://issues.apache.org/jira/browse/SOLR-5478?focusedCommentId=16036951&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16036951
> - 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201706.mbox/%3C008201d2ddf9%2429435740%247bca05c0%24%40thetaphi.de%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to