The README.txt file and handbook state:
Also, due to the way Solr works, using a single field for fulltext searching will result in the smallest index size and best search performance, as well as possibly having other advantages, too. Therefore, if you don't need to search different sets of fields in different searches on an index, it is adviced that you collect all fields that should be searchable into a single field using the “Aggregated fields” data alteration.
I could not find anything on the web on performance loss when using fulltext search on multiple fields. Is this applicable to all Solr versions (using v4.5.1)? Also on relatively small sites with a few hundred / thousand nodes of average size indexed? Is there more info available on the "possible other advantages" on using a single field for fulltext searches?
I am asking since I am fairly new to Solr, playing around with it and looking for a way to use Solr and the HTML filter with HTML tag boosts (this does not work out of the box, does it? :-). One possibility is to split up selected fields into ie. tm_body$value$h1, tm_body$value$h2 etc. and fulltext search them separately. Is this being advised against?
Any input is welcome, thanks a lot in advance!
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | README.txt | 7.39 KB | drunken monkey |
Comments
Comment #1
drunken monkeyAs chance would have it, I stumbled across this again myself a couple of days ago and thought about whether we shouldn't remove this paragraph. There unquestionably is a performance penalty to using multiple fields (and, though I could not find it just now, I'm positive I've read it somewhere in the Solr documentation as well), but I don't think it's really noticable, let alone considerable. And on small sites, you can generally do almost anything with Solr without noticing a drop in performance. The main performance factor there will always be Drupal and, possibly, the communication with the Solr server.
And yes, especially if you want to have different boosts for fields, you should of course use different fields (or, rather, you have to). I hope you are aware that for what you suggest you'd have to use some custom code, but other than that I don't think there's any problem with it.
Attached is a patch that would remove the warning from
README.txt. I think it's really more confusing than helpful and we can't document all tiny performance considerations there, anyways. I also removed it from the handbook entry.Comment #2
lmeurs commentedExcellent, thank you for the quick reply and clarification!
Comment #3
drunken monkeyCommitted the README.txt changes.