>> You end up with one multivalued field, which means that you can only have one analyzer chain. <<
actually two of the three fields being considered for combination in to a single field ARE multivalued fields. would this be an issue? >> With separate fields, each field can be analyzed differently. Also, if you are indexing and/or storing the individual fields, you may have data duplication in your index, making it larger and increasing your disk/RAM requirements. << this makes sense >> That field will have a higher termcount than the individual fields, which means that searches against it will naturally be just a little bit slower. << ok >> Your application will not have to do as much work to construct a query, though. << actually this is the primary reason this came up. >> If you are already planning to use dismax/edismax, then you don't need the overhead of a copyField. You can simply provide access to (e)dismax search with the qf (and possibly pf) parameters predefined, or your application can provide these parameters. http://wiki.apache.org/solr/ExtendedDisMax << can you elaborate on this and how EDisMax would preclude the need for copyfield? i am using extended dismax now in my response handlers. here is an example of one of my requestHandlers <requestHandler name="partItemNoSearch" class="solr.SearchHandler" default="false"> <lst name="defaults"> <str name="defType">edismax</str> <str name="echoParams">all</str> <int name="rows">5</int> <str name="qf">itemNo^1.0</str> <str name="q.alt">*:*</str> </lst> <lst name="appends"> <str name="fq">itemType:1</str> <str name="sort">rankNo asc, score desc</str> </lst> <lst name="invariants"> <str name="facet">false</str> </lst> </requestHandler> Thanks, Shawn -- View this message in context: http://lucene.472066.n3.nabble.com/is-there-a-downside-to-combining-search-fields-with-copyfield-tp3905349p3906265.html Sent from the Solr - User mailing list archive at Nabble.com.
