Steven,
The case that I was pointing to was specifically talking about the need for
a int to be set to multivalued=true for the field to be used as a
facet.field. I personally ran into it when upgrading to 5.x from 4.10.2. I
believe setting docValues=true will not have an affect (untested by me
Thanks Erick.
What about Solr defect SOLR-7495 that Nick mentioned? It sounds like
because of this defect, I should NOT set docValues="true" on a filed when:
a) type="int" and b) multiValued="true". Can you confirm that I got this
right? I'm on Solr 5.2.1
Steve
On Fri, May 27, 2016 at 1:30
bq: my index size grew by 20%. Is this expected
Yes. But don't worry about it ;). Basically, you've serialized
to disk the "uninverted" form of the field. But, that is
accessed through Lucene by MMapDirectory, see:
http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
If you
Although you did mention that you wont need to sort and you are using
mutlivalued=true. On the off chance you do change something like
multivalued=false docValues=false then this will come in to play:
https://issues.apache.org/jira/browse/SOLR-7495
This has been a rather large pain to deal with
I always prefer ints to strings, they can't help but take
up less memory, comparing two ints is much faster than
two strings etc. Although Lucene can play some tricks
to make that less noticeable.
Although if these are just a few values, it'll be hard to
actually measure the perf difference.
And
Hi everyone,
I will be faceting on data of type integers and I'm wonder if there is any
difference on how I design my schema. I have no need to sort or use range
facet, given this, in terms of Lucene performance and index size, does it
make any difference if I use:
#1:
Or
#2:
(notice how I
