eDisMax is the query parser most production Solr deployments run on. It takes the words a user typed, spreads them across the fields you nominate, decides how many of those words a document has to contain, and rewards documents where the words appear together. This guide covers every parameter that does that work — qf, mm, pf, pf2, pf3, ps, ps2, ps3 — and shows the exact query Solr builds for each one.
The words the user typed stay in q. Everything that shapes ranking lives in separate parameters.
Every parsed query printed on this page is a real capture from a live Opensolr index, taken with debugQuery=true. None of it is illustrative.
01 · What eDisMax actually does
DisMax stands for disjunction maximum: each term is run against several fields at once and the field that scores best is the one that counts. eDisMax is the extended version. It keeps that behaviour and adds full Lucene syntax, shingle-based phrase boosting, function boosting and a set of controls that make relevance tuning a configuration job rather than a string-building job.
The query string stays clean
Field names, weights and boolean logic live in parameters. q holds nothing but what the user typed, which is also what makes query logging, spellcheck and analytics meaningful.
The best field wins, not the sum
A term present in three fields does not score three times. eDisMax takes the highest-scoring field, then adds tie multiplied by the rest. tie defaults to 0.0, which is pure winner-takes-all; 0.1 is the common working value.
User input rarely produces an error
eDisMax first reads the query as Lucene syntax. If that fails it escapes the offending characters and tries again, so a stray quote or a trailing AND becomes text instead of an HTTP 400.
Real operators when someone types them
+, -, AND, OR, NOT, field:value and parentheses all work, which plain DisMax does not support.
Words that travel together are rewarded
Documents holding the query words next to each other, in order, can be lifted above documents that merely contain all of them. That is the entire purpose of pf, pf2 and pf3.
The parameters, one page each
qf: which fields count, and how much
Spread the words over the fields you name, each with its weight.
The only parameter that decides which documents are in the result set.
pf, pf2, pf3 and ps: phrase boosting and slop
Reward documents where the words travel together, and decide how far apart is still a phrase.
How the score is built, and where each parameter lives
The final score, piece by piece, and handler defaults against request parameters.
Worked examples and tuning in practice
Short, long and overridden queries, and the order in which to tune.
The same parameters, on Opensolr
Everything above is standard Solr and works the same on any installation. On Opensolr you edit schema.xml and solrconfig.xml in the control panel (edit a file), and saving reloads the index.
On an index with site search, the hosted search page builds qf, pf, pf2 and pf3 from one set of field weights, and passes Minimum Match through as literal mm syntax. You set both in the Search Tuning panel, read at query time, with no reload: search tuning, field weights, minimum match.
Opensolr builds qf, pf, pf2 and pf3 from one set of field weights, with the phrase multipliers shown.
Hybrid search: the keyword scoring described here, combined with matching by meaning, in the same request.
Query Elevation: pin or exclude documents for the few queries where ranking is wrong, instead of bending the boosts for everyone.
Clicks and CTR: many impressions and few clicks on a query point at mm or phrase work.
Error Audit: a malformed query or a missing field shows up there before a visitor reports it.