Exercise 1: Why the Search-vs-Structured Relationship Is Reversed From Postgres's Own — Possible Solution
====================================================================

WHAT THIS CHAPTER STATES DIRECTLY
------------------------------
Per this chapter, "Elasticsearch and OpenSearch flip this arrangement.
The inverted index... and relevance scoring... are the primary,
founding data structure and query model — not a bolt-on feature.
Structured, analytical querying (search1-7's own aggregations) is
built on top of that search-first foundation, the reverse of
Postgres's own 'relational engine with search bolted on' arrangement."

POSTGRES'S OWN ARRANGEMENT
------------------------------
Per postgres1-6, Postgres is "fundamentally relational, with full-text
search as a real but genuinely secondary add-on." In Postgres, the
PRIMARY data structure and query model is the relational table —
ordinary rows, columns, and B-tree indexes designed around exact
matching and ordering. Full-text search (tsvector/tsquery, per
postgres1-6) is a genuinely useful FEATURE added on top of that
already-relational foundation, using GIN indexes as an addition to the
engine's own primary indexing strategy, not as the engine's own reason
for existing.

WHY ELASTICSEARCH/OPENSEARCH'S OWN ARRANGEMENT IS THE REVERSE
------------------------------
In Elasticsearch/OpenSearch, per this chapter, the inverted index and
relevance scoring ARE the engine's own foundational data structure and
query model — the entire system is architected around efficiently
answering "which documents best match this search" from the ground
up. Structured, exact-match, or analytical querying (aggregations,
covered in search1-7) is then built ON TOP of that already-search-
oriented foundation, rather than the other way around. Where Postgres
starts from "store and query structured rows, with search as an
add-on," Elasticsearch/OpenSearch starts from "index and rank
documents for search, with structured querying layered on top of
that."

WHY THIS IS GENUINELY "REVERSED" RATHER THAN JUST "DIFFERENT"
------------------------------
Both systems ultimately offer BOTH capabilities (structured querying
and search), but the direction of "which one is foundational and
which one is added" is precisely inverted between the two — Postgres
adds search onto a relational foundation; Elasticsearch/OpenSearch
adds structured/analytical querying onto a search foundation. This
is why the chapter specifically calls it the "reverse," not merely
"another way of doing similar things."

WHY THIS WORKS AS AN ANSWER
------------------------------
It states both engines' own foundational-vs-added relationship
precisely, using the chapter's own wording and postgres1-6's own
prior characterization of Postgres, and explains specifically why
"reverse" is the accurate word rather than simply "different."