Question about boost field deprecation in 1.0.0.rc1


(janosz.krzysztof) #1

Hello,

I have question about boost field deprecation in 1.x version. What should
now be a proper way (with regards to performance) to achieve similar
functionality?
I've made some tests (using java api, in version 1.0.0.rc2) which was
comparing quering using _all field, MultiMatch and QueryString. Result were
so, that _all query was the fastest, while QueryString was ~1.9x times
slower (and MultiMatch being from 2.5 to 3x times slower).
So my question is, what should be the most appropriate way to replace text
quering using _all field boosted in index time by each included field?

Thanks in advance,
Krzysztof Janosz

--
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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/7ea54dd9-fbd7-4158-8900-18554df9aaf7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(janosz.krzysztof) #2

I've checked multi match with cross_fields (sources compiled from master
branch), and performance are so that query string is still better (~270ms
per query compared to ~440ms in multi match) and still significantly
noticeably worse than using _all field (~140ms).

PS: Tests are done using java api and querying 1m record 1000 times in two
cases (12 fields and 21 fields) with 10% query warmup.

Regards,
Krzysztof Janosz

--
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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/d3b90075-201d-4c20-bf30-735b969fa36a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(system) #3