Faceting

facet.interval counts documents against a fixed set of explicit brackets rather than a uniform gap, using mathematical interval notation: [ / ] for inclusive, ( / ) for exclusive. It scans the field once for however many facet.interval.set values are given, which makes it cheaper than several overlapping facet.query ranges over the same field.

\{!key=…​} renames a facet’s key in the response, independently of ex/tag — combine them in one local-params block: facet.field=\{!ex=colorFilter key=colors}color. This is what lets a client issue the same field faceted twice with different exclusions (e.g. one narrowed, one not) without a response key collision.

type: terms is the JSON equivalent of facet.field, with the same limit/offset/mincount/ sort/prefix knobs as JSON keys instead of facet.* parameters, plus numBuckets (return the total distinct-value count alongside the page) and allBuckets (add a rollup bucket summing every bucket, matched or not, including ones dropped by limit).

type: range mirrors facet.range: field, start, end, gap, hardend, include, other. It also accepts ranges, an explicit array of { "from": …​, "to": …​, "inclusive_from": …​, "inclusive_to": …​ } objects, when the bands aren’t evenly spaced — something facet.range alone cannot express without falling back to facet.interval.

type: query produces one bucket — the subset of the domain also matching q — to scope metrics or sub-facets to a condition, the JSON equivalent of facet.query but able to carry nested facet and domain blocks of its own.

type: heatmap counts documents into a grid of geospatial cells over a spatial field, returning a compact counts matrix (or PNG) suitable for rendering a density overlay on a map. geom bounds the region, gridLevel (or distErrPct) controls cell resolution. See Spatial search for the spatial field types it runs over.

Any facet bucket — the top-level domain included — can carry sibling keys that are metric expressions instead of nested facets: sum(field), avg(field), min(field), max(field), unique(field) (exact distinct count within the bucket, unlike Elasticsearch’s approximate cardinality), percentile(field,50,95,99), variance(field), stddev(field), and missing(field). These are the leaves of the tree, exactly the way an Elasticsearch metric aggregation is always a leaf under a bucket aggregation — see Aggregations.

uniqueBlock(…​) is a specialized, cheaper unique for counting parent documents from within a nested-document (block-join) child domain — it counts blocks without touching the filter cache the way a generic unique on a join-derived field would.

Any facet’s facet key can itself hold more named facets, each computed within that bucket’s own subset of the domain — the same relationship a terms sub-aggregation under another terms has in Elasticsearch. There is no fixed depth limit; watch the bucket product across levels the same way you would there.

By default every facet’s domain is its parent’s bucket (and the root facet’s domain is the main query’s matches). A domain block overrides that:

blockChildren/blockParent need the same parent/child block-join document layout used by the \{!child of=…​}/\{!parent which=…​} query parsers covered in Partial updates & concurrency. Cross-collection or cross-field lookups that aren’t a parent/child block use join instead, mirroring the \{!join} query parser from Core concepts & architecture.

Every bucketing facet type accepts a method: dv (docValues, iterate matching documents and increment per-value counters — the JSON Facet equivalent of facet.method=fc/fcs), dvhash (docValues with a hash table, better for very high cardinality), stream (walk indexed terms in sorted order and stream results without collecting every bucket in memory — unbounded cardinality at the cost of losing sort-by-metric, since buckets emit in key order), uif ("UnInvertedField", legacy field-cache faceting), and smart (the default — Solr picks per field/query shape). stream requires sort: "index asc" and no facet.limit-style paging; it exists for the same reason Elasticsearch’s composite aggregation does — enumerating every bucket of a huge-cardinality field without the top-N accuracy caveat that a bounded terms/facet.field carries.

relatedness(foreground, background) scores how strongly a bucket’s values correlate with a foreground query relative to a background query — e.g. which genres are disproportionately common among five-star reviews compared to all reviews. It returns a relatedness_value (roughly -1 to 1) plus the raw foreground_count/foreground_size/background_count/background_size it was computed from, and accepts min_popularity (skip buckets too small to be statistically meaningful) and sweep_collection (tune the two-pass execution strategy for large domains).

This is the tool for "what stands out" questions — it has no direct classic-facet or Elasticsearch aggregation equivalent; the closest analogue on the Elasticsearch side is the significant_terms aggregation.