How do the sampler and diversified_sampler aggregations bound the cost of expensive sub-aggregations?

## The problem they solve Some aggregations cost far more per document than a simple count. `significant_terms` compares foreground and background frequencies; scripted metrics execute code per hit; nested `terms` trees multiply state. When the query matches millions of documents, running such an aggregation over all of them is expensive and often unnecessary — the analysis you want ("what vocabulary distinguishes these results?", "what do the best matches have in common?") is answerable from a representative slice. `sampler` and `diversified_sampler` are single-bucket aggregations that define that slice. They collect a bounded set of documents per shard and expose it as one bucket; whatever sub-aggregations you nest inside see only those documents. ## sampler `sampler` takes one parameter that matters: `shard_size`, the maximum number of documents to collect **per shard**, defaulting to 100. It keeps the highest-scoring ones. Total sample size is therefore roughly `shard_size` times the number of shards queried, which is worth remembering — the same request against a 30-shard index samples thirty times as many documents as against a single shard, so tuning `shard_size` without knowing the shard count is guesswork. Because selection is by score, `sampler` is only coherent under a scoring query. Wrap a `match` query and "top 100" means the 100 best matches. Run it under a `filter` clause, a `bool` with only `filter`, or a `constant_score`, and every document has an identical score, so which 100 you get is an implementation detail — the sample becomes arbitrary rather than representative. This is the single most common misuse. The response includes the bucket's `doc_count`, which tells you how many documents the sample actually held. ## diversified_sampler A score-ordered sample has a failure mode: one source can own the top results. Search a support corpus for a product name and the top 100 hits may all be replies in one long thread; the resulting `significant_terms` then describes that thread rather than the topic. `diversified_sampler` fixes this by adding a diversification key — `field` or `script` — plus `max_docs_per_value`, which defaults to 1. At most that many sampled documents may share a given key value, so the sample spans distinct threads, authors, domains or customers. `shard_size` still caps the total per shard, and `execution_hint` (`global_ordinals`, `bytes_hash`, or `map`) chooses how the seen-values structure is held, trading memory against speed the same way the `terms` aggregation's hint does. The diversification key must be single-valued per document; a multi-valued field is not a legal choice. If the field's values are so uniform that the cap cannot be satisfied, the sample simply comes back smaller than `shard_size` — worth checking `doc_count` before drawing conclusions. ## What you give up Everything inside a sampler is an estimate over a biased-by-score subset. Counts, sums and averages computed inside one are not the counts, sums and averages of the match set, and presenting them as such is a correctness bug, not a performance tradeoff. Use samplers for *discovery* — significant terms, exploratory facets, "what characterizes these results" — and never for reporting figures a user will treat as authoritative. They also do nothing for the query itself. The query still matches every document; only the sub-aggregation work is bounded. If the query is what hurts, filter harder or narrow the time range. ## Where they sit among the alternatives Given an aggregation that is too expensive, the ladder is roughly: narrow the query first (cheapest and exact); reduce the aggregation's own size and depth; switch to `composite` paging if you need every bucket; sample if approximation is acceptable and the query scores; and pre-aggregate with a transform if the same analysis runs repeatedly. Sampling is the right rung specifically when the analysis is exploratory and the match set is large and score-ordered — a narrow but real slot. ## Interview register This is a differentiator question. Knowing that `sampler` exists is worth little; knowing that it selects by score and is therefore meaningless in a pure filter context, and that `diversified_sampler` exists precisely because score-ordered samples over-represent prolific sources, shows you have used them on a real corpus.