On Mon, Nov 9, 2015 at 10:55 AM, Demian Katz <demian.k...@villanova.edu> wrote: > I understand that by adding "docValues=true" to some of my fields, I can > improve sorting/faceting performance.
I don't think this is true in the general sense. docValues are built at index-time, so what you will save is initial un-inversion time (i.e. the first time a field is used after a new searcher is opened). After that point, docValues may be slightly slower. The other advantage of docValues is memory use... much/most of it is essentially "off-heap", being memory-mapped from disk. This cuts down on memory issues and helps reduce longer GC pauses. docValues are good in general, and I think we should default to them more for Solr 6, but they are not better in all ways. > However, I have a couple of questions: > > > 1.) Will Solr always take proper advantage of docValues when it is turned > on Yes. > , or will I gain greater performance by turning of stored/indexed in > situations where only docValues are necessary (e.g. a sort-only field)? > > 2.) Will adding docValues to a field introduce significant performance > penalties for non-docValues uses of that field, beyond the obvious fact that > the additional data will consume more disk and memory? No, it's a separate part of the index. -Yonik > I'm asking this question because the existing schema has some multi-purpose > fields, and I'm trying to determine whether I should just add > "docValues=true" wherever it might help, or if I need to take a more > thoughtful approach and potentially split some fields with copyFields, etc. > This is particularly significant because my schema makes use of some dynamic > field suffixes, and I'm not sure if I need to add new suffixes to > differentiate docValues/non-docValues fields, or if it's okay to turn on > docValues across the board "just in case." > > Apologies if these questions have already been answered - I couldn't find a > totally clear answer in the places I searched. > > Thanks! > > - Demian
