Exercise 2: How Search + Aggregations Powers a Faceted Search Sidebar — Possible Solution
====================================================================

THE WORKED EXAMPLE
------------------------------
Per this chapter's own worked example:

  POST /products/_search
  {
    "query": { "match": { "description": "wireless mouse" } },
    "aggs": {
      "by_category": { "terms": { "field": "category" } },
      "price_ranges": {
        "range": {
          "field": "price",
          "ranges": [
            { "to": 25 }, { "from": 25, "to": 50 }, { "from": 50 }
          ]
        }
      }
    }
  }

HOW THIS POWERS A REAL FACETED SEARCH SIDEBAR
------------------------------
Per this chapter, "this is exactly what powers a real e-commerce
faceted search sidebar — search results, category counts ('12 in
Electronics, 8 in Home Goods'), and price-range checkboxes, all
computed over the same filtered result set, in one round trip." The
single query above simultaneously: (1) runs the actual full-text
search ("wireless mouse") that produces the ranked list of matching
products a user sees as their search results; (2) via the by_category
terms aggregation, counts how many of those SAME matched products fall
into each distinct category, giving the exact numbers ("12 in
Electronics") a sidebar's category filter checkboxes would display; and
(3) via the price_ranges range aggregation, counts how many of those
SAME matched products fall into each price bracket, giving the counts
a price-range filter UI would display. All three pieces of information
— the results themselves, the category breakdown, and the price-range
breakdown — come back together in a SINGLE response to a SINGLE
request, computed over the identical, already-filtered set of matching
documents.

WHY THIS RESOLVES POSTGRES1-6'S OWN "FACETED SEARCH AS A FIRST-CLASS
FEATURE" CALLOUT
------------------------------
postgres1-6 named "faceted search as a first-class feature" as
something a dedicated search engine offers that Postgres's own
built-in full-text search doesn't attempt to match, without yet
demonstrating exactly what that means in practice. This chapter's own
worked example makes that concrete: achieving the identical result in
a purely relational system would require either running several
separate queries (one for the search results, one for the category
counts filtered the same way, one for the price-range counts filtered
the same way) or constructing a considerably more complex combined
query — and per this chapter's own earlier section, even then, SQL's
own execution model "wasn't built around the search-then-facet pattern
as a first-class combined operation" the way this single aggregations-
plus-query request is.

WHY THIS WORKS AS AN ANSWER
------------------------------
It walks through the worked example clause by clause, mapping each
piece (query, by_category, price_ranges) to the specific real-world UI
element it powers, and explicitly ties the demonstration back to
postgres1-6's own named-but-undemonstrated callout, showing exactly
what that callout meant in concrete terms.