Functionally, the two options are equivalent, and I've never really heard of any speed difference. Assuming it's not that big a programming change, though, you probably want to just test...
Do be aware of one subtle difference in the approaches, though. If the increment gap is != 1 then multiValued fields will NOT be functionally equivalent because phrases won't match across boundaries quite the same way. Which is often desirable behavior but may not be in your situation. Best Erick On Mon, Jan 17, 2011 at 5:50 AM, kenf_nc <ken.fos...@realestate.com> wrote: > > No, I have both, a single field (for free form text search), and individual > fields (for directed search). I already duplicate the data and that's not a > problem, disk space is cheap. What I wanted to know was whether it is best > to make the single field multiValued="true" or not. That is, should my > 'content' field hold data like: > some description maybe a paragraph or two > a product or service title > tag1 > tag2 > feature1 > feature2 > or would it be better to make it a concatenated, single value field like: > some description maybe a paragraph or two a product or service title > tag1 tag2 feature1 feature2 > > my indexing seems to take longer than most, it takes about 2 1/2 hours to > index 3.5 million records. I have a colleague that, in a separate project, > is indexing 70 million records in about 4 hours, albeit in a much simpler > schema. So I'm trying to see if this could be a factor in my indexing > performance. I also wanted to know what impact, in general, not just in > this > situation, using a MultiValued field versus a Single Valued field has in > search results. > > I would have thought that having to support a free-form-text search, and a > field (directed) search would be a common problem, and was just looking for > advice. > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Single-value-vs-multi-value-setting-in-tokenized-field-tp2268635p2271543.html > Sent from the Solr - User mailing list archive at Nabble.com. >
