Solr and PhraseQuery – phrase bonus in query stage

In the majority of system implementations I dealt with, sooner or later, there was a problem – search results tunning. One of the simplest ways to improve the search results quality was phrase boosting. Having the three most popular query parsers in Solr and the variety of parameters to control them I though it will be a good idea to check how they behave and how they affect performance.

In the current trunk of Solr we have three query parsers:

  • Standard Solr Query Parser – default parser for Solr based on Lucene query parser
  • DisMax Query Parser
  • Extended DisMax Query Parser

Each of the mentioned query parsers have its own capabilities in case of phrase boosting on query stage. I wont mention index time term proximity in this post – Ill get back to it some other time. So, about the parsers now.

Standard Solr Query Parser

Parser based on Standard Lucene Query Parser and enhancing its parent capabilities. When it comes to phrase boosting, we dont have much choice. Lets say, that our system is a search system for large Internet library, where users can rate books, leave comments and discuss books in the library forums. Our goal is to index all the data generated by the users and our suppliers and then represent this data in our search results. When user search for "Java design patterns"  we want to show him the books that have those words in a document. No problem, lets make a Solr query like this:


So we get the results and we can say that our search engine is behaving well and we dont want to improve search quality. But I would add another part to the query – part that would favor document which have a phrase (words given to the query are next to each other in the document) in the search-able fields. Its an easy step, our modified query would look like this:


By adding that additional query part (+OR+"java+design+patterns"^30) we modified our search results - by adding that part, on the first position in our result we now have books which have the exact phrase in the search fields. Lucene query generated by the parser look like that:

Search results for above query as follows:

DisMax Query Parser

In addition to constructing queries in such a manner as described above, we can use the parameter pf and modify its behavior by using the ps parameter. Pf parameter provide information about the fields in which phrases will be identified. Pf parameter is often used in a manner analogous to the parameter qf specifying a list of search-able fields. In addition to that, we must specify the boost parameter for the phrase otherwise the default boost will be taken into consideration. The query using DisMax would look like that:


While the query passed to Lucene looks as follows:

The results for the query thus constructed are as follows:

It is noteworthy that the order of results for both methods is the same. This follows from the fact, that the phrase has been identified only in the document with the id of 1.Look that there is no difference in the value of score for the first document in both methods. Of course the other documents, located on positions from 2 to 5, are in both cases on the same positions, but have different score values because of the difference in query passed to Lucene.

But, I used the ps parameter (set to 0) and didnt mention why I did it. When You use the pf (and pf2, but more on that later) parameter, the ps parameter mean Phrase Slop – a maximum distance of words from each other to form a phrase. For instance, ps=2 will mean that the words can be a maximum of two places from each other to form a phrase. Note, however, that despite the fact that both the “Java sample design patterns” and “Java design patterns” will create a phrase, but the document entitled “Java design patterns” will have a bigger score value, despite the settings ps=2, because of terms located closer together.

Extended DisMax Query Parser

Unfortunately without the use of trunk You can not use eDisMax. But, anyway, the query using eDisMax Enhanced Term Proximity Boosting would look like that:


The above query creates the following query to Lucene:

As seen, in addition to the standard DisjunctionMaxQuery produced by DisMax (and this its expanded version), extended DisMax parser also produced two additional queries – the ones responsible for enhanced term proximity boosting.  The additional queries boosts pair of word created from the terms in the user query. In the presented case the created test pairs were “java design” and “design patterns”. As you can guess the most significant documents in the results list, documents will be generated by having both pairs, the next document will have one of the pair, and another will not have any. As proof I present the result of the above query send to Solr:

As you can see the first document has not changed its position. The second and third place are the documents that have one of the pairs generated by the parser. As a result documents with id 2 and 5 have the same coefficient score value. The result list is closed by the documents with only terms present in the search-able fields.


In any case, it must be taken into account that individual features will affect the performance of applications based on Solr. I thought I`ll do a simple performance test. The assumptions of the test are quite simple – index data from wikipedia and for each phrase boost method create five queries – each of the queries assembled from two to six tokens. Solr cache disabled, restart of Solr after each query. The result is the arithmetic mean of 10 repetitions of each test. Before the test results, a few words about the index:

  • Number of documents in the index: 1,177,239
  • Number of segments: 1
  • Number of terms: 18.506.646
  • Number of term/document pairs: 230.297.212
  • Number of tokens: 418.135.268
  • The size of the index: 4.6GB (optimized)
  • Lucene version used to build the index: 4.0-dev 964000

Phrases that were selected for each iteration of the test:

  • Iteration I: “Great Peter”
  • Iteration II: “World War Two”
  • Iteration III: “World War Two Germany”
  • Iteration IV: “Move Time Eastern Poland Reformation”
  • Iteration V: “Change Winter Cloths To Summer Cloths Now”

The results were as follows:

Standard Solr Query ParserDisMax Query ParserExtended DisMax Query Parser

Please note that the reported results concern only the issue of performance and are not suggesting a method of phrase boosting. The choice of method is a matter of requirements and implementation. As for the results, you can see that the DisMax method is the quickest one.

3 thoughts on “Solr and PhraseQuery – phrase bonus in query stage

  • 11 October 2011 at 19:40


    Just wanted to say this is an awesome blog. I’ve not being using Solr for long and found many of your articles to be very helpful.



  • 18 February 2012 at 18:36


    I’m using Django Haystack with Solr on the back,
    I understand well truly what you have described in this blog, however, I am having trouble to work out what file needs to be configured and how to configure it in order for solr not to break my search word. As an example, i search for “Accounting” solr breaks it into “Account”, and all the record with “Account” Shows up first, and when i search for “Management Accounting”, the records with “Management Accountancy” shows up, I used double-quote for the phrase, but I want to know how do I go about not having my english word broken for the search?! Thanks.

    • 19 February 2012 at 13:03

      It’s hard to tell anything without seeing the schema, but I assume that the thing you are seeing is because the stemmer works. If you don’t know what stemming is, please take a look at the following URL: . If you want to avoid that, just remove the stemming filter from the field type and reindex Your data.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.