Hi Jack, I've just started to dig into this as well, so sharing what I know but still some holes in my knowledge too.
DocValues == Column Stride Fields (best resource I know of so far is Simon's preso from Lucene Rev 2011 - http://www.slideshare.net/LucidImagination/column-stride-fields-aka-docvalues). It's pretty dense but some nuggets I've gleaned from this are: 1) DocValues are more efficient in terms of memory usage and I/O performance for building an alternative to FieldCache (slide 27 is very impressive) 2) DocValues has a more efficient way to store primitive types, such as packed ints 3) Faster random access to stored values In terms of switch-over, you have to re-index to change your fields to use DocValues on disk, which is why they are not enabled by default. Lastly, another goal of DocValues is to allow updates to a single field w/o re-indexing the entire doc. That's not implemented yet but I think still planned. Cheers, Tim On Fri, Mar 29, 2013 at 9:31 AM, Jack Krupansky <j...@basetechnology.com>wrote: > I’m still a little fuzzy on DocValues (maybe because I’m still grappling > with how it does or doesn’t still relate to “Column Stride Fields”), so can > anybody clue me in as to how useful DocValues is/are? > > Are DocValues simply an alternative to “stored fields”? > > If so, and if DocValues are so great, why aren’t we just switching Solr > over to DocValues under the hood for all fields? > > And if there are “issues” with DocValues that would make such a complete > switchover less than absolutely desired, what are those issues? > > In short, when should a user use DocValues over stored fields, and vice > versa? > > As things stand, all we’ve done is make Solr more confusing than it was > before, without improving its OOBE. OOBE should be job one in Solr. > > Thanks. > > P.S., And if I actually want to do Column Stride Fields, is there a way to > do that? > > -- Jack Krupansky
