Why can Elasticsearch's rank_feature and distance_feature queries be cheaper than an equivalent function_score?

## Wrapper versus query `function_score` wraps a query and rewrites its scores. That wrapping is what costs: for every document the inner query matches, the functions must run, because the engine has no way to know that a given document's function result could not lift it into the top hits. Broad queries therefore pay a per-document cost across the whole match set. `rank_feature` and `distance_feature` are queries in their own right. They can appear directly in a `bool`'s `should` array beside the text query, and their contributions add into the same score sum as any other clause. Crucially, each has a computable ceiling on how much it can contribute, which lets the top-k collection logic discard documents whose best possible total is already below the current worst hit. That skipping is the source of the performance difference. ## rank_feature A `rank_feature` field holds one strictly positive numeric value per document — a popularity score, a PageRank-like authority, a quality signal. `rank_features` is its sibling for a sparse map of many named features on one document. The field takes `positive_score_impact`, which defaults to `true`. Setting it to `false` inverts the relationship, so a lower value scores higher — the way to express "faster page load ranks better". The `rank_feature` query applies one of several bounded functions to the stored value: - `saturation` is the default and computes a curve that rises quickly at small values and approaches a ceiling. It takes a `pivot`, the value at which the function reaches half its maximum; if you omit it, an approximation is derived from the values in the index. This is the shape most popularity signals want: the difference between 10 and 100 should matter far more than the difference between 100,000 and 1,000,000. - `log` requires a `scaling_factor` and grows logarithmically, useful when the signal keeps meaning something at large magnitudes. - `sigmoid` takes a `pivot` and an `exponent` and gives an S-curve whose steepness you control. The cost of this design is narrowness. A `rank_feature` field exists to be queried by the `rank_feature` query; if you also need to sort, aggregate or filter on the same number, index a plain numeric copy of it alongside. The value must also be strictly positive, and updating it means updating the document. ## distance_feature `distance_feature` covers the recency and proximity cases. It works on `date`, `date_nanos` and `geo_point` fields and takes an `origin` (`"now"`, a timestamp, or coordinates), a `pivot`, and an optional `boost`. Its score is `boost × pivot / (pivot + distance)`, so `pivot` is the distance at which the contribution falls to half of `boost`. Like `rank_feature`, its output is bounded above by `boost`, which is exactly what makes skipping possible. Against a `gauss` decay function it is less expressive — one curve shape, no `offset` plateau — but it is a query, so it composes into `bool` naturally and adds rather than multiplies. That additive placement is often the better relevance design anyway: a fresh document gains a bounded amount, and no amount of freshness can bury a far better text match. ## Composing them The idiomatic shape is a single `bool` where the text query is the `must` and the signals are `should` clauses: ```json { "bool": { "must": [ { "match": { "body": "kafka rebalance" } } ], "should": [ { "rank_feature": { "field": "pagerank", "saturation": { "pivot": 10 } } }, { "distance_feature": { "field": "published_at", "origin": "now", "pivot": "30d", "boost": 2 } } ] }} ``` Every contribution is bounded, each is independently tunable via its `boost`, and no clause can dominate the others by orders of magnitude the way an unbounded multiplicative factor can. ## When function_score is still right These two queries cover a specific pair of signal shapes. When the signal is not a static per-document value or a distance — when it is a conditional business rule, a formula across several fields, a random shuffle, or a case where multiplying rather than adding is genuinely correct — `function_score` (or `script_score`) remains the tool. The engineering judgment is to use the bounded, indexed form for the common popularity and recency cases, which are also the highest-traffic ones, and keep the general mechanism for the genuinely irregular remainder. ## What an interviewer is listening for The key sentence is that skipping requires a known upper bound on a document's possible contribution. Candidates who answer only "rank_feature is faster" have memorised a fact; candidates who explain why a bounded, indexed contribution enables top-k pruning while an arbitrary function does not have understood the mechanism, and the same reasoning transfers to other parts of the engine.