>one significant shortcoming is that you cannot do any highlighting. Not necessarily true - see this feature which is primarily for the use case of searching on an "all" type field but highlighting results using detailed fields: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-highlighting.html#field-match
Bear in mind that when searching across multiple fields Lucene's natural tendency to favour rare terms will do odd things like ranking the most bizarre interpretation of field choice e.g. firstName:Smith ranks higher than lastName:Smith. The multi-match query has some special features built into the cross-field matching modes to counter-act this tendency. http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-multi-match-query.html#type-cross-fields Cheers Mark On Thursday, September 25, 2014 11:08:44 AM UTC+1, mooky wrote: > > > The _all field is super-convenient for doing a google-style search across > all fields of a document. The mapping makes it easy to include/exclude > fields from _all in a declarative fashion - including boost levels etc. > It is a pattern I have been using for many years - by hand using lucene > (before elastic), using zzz_all (or whatever it was called) in Compass and > it has served me an my users well. > > However, one significant shortcoming is that you cannot do any > highlighting. (And there are probably some other shortcomings I am not > aware of...) > > I read in the documentation: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/search-lite.html > > TIP:The _all field is a useful feature while you are getting started with >> a new application. Later, you will find that you have more control over >> your search results if you query specific fields instead of the _all field. >> When the _all field is no longer useful to you, you can disable it, as >> explained in Metadata: _all field >> <http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/root-object.html#all-field> >> . > > > And this lead me to re-thinking how it might be done. > > I can turn the problem inside-out. Instead of using _all, I could instead > create a more complicated query across all of the fields that are included > in _all. I can dynamically generate the query from my field metadata (an > enum). > > My question mark is what kind of effect that will have on performance > given I am indexing structured data (not text, per se). > To give an example, one of my documents has 115 (!) fields. > > So my query will go from: > > { > "query" : { > "prefix" : { > "_all" : { > "prefix" : "moo" > } > } > } > } > > > > To > > { > "bool" : { > "should" : [ > {"prefix" : { "field1" : "moo" }}, > {"prefix" : { "field2" : "moo" }}, > {"prefix" : { "field3" : "moo" }}, > {"prefix" : { "field4" : "moo" }}, > {"prefix" : { "field5" : "moo" }}, > {"prefix" : { "field6" : "moo" }}, > . > . > . > {"prefix" : { "field114" : "moo" }}, > {"prefix" : { "field115" : "moo" }}, > ] > } > } > > > Ouch. No? > What kind of performance impact will this have? Diabolical? > > The upside is that I now have the flexibility to get some meaningful > highlighting .... but at what cost? > Anyone have experience with this? > > Cheers, > -N > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/cc4ccc93-0d69-4f64-b7d0-db878d0c0b9b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
