Exercise 2: The Connection to postgres1-7's Own GIN Material — Possible Solution
====================================================================

THE SAME UNDERLYING CONCEPT
------------------------------
Per this chapter, "postgres1-7 explained GIN as storing 'a mapping
from each individual component of a value... to the list of rows
containing it.' That's genuinely, literally the same core concept —
an inverted index — just applied at smaller scale." GIN, as covered in
postgres1-7, works by breaking a composite value (a JSONB document, a
tsvector's own set of lexemes) apart into its individual COMPONENTS,
and storing a mapping from each component back to the rows that
contain it — precisely the same term-to-document (or component-to-row)
mapping structure this chapter just explained as the inverted index.
There isn't a conceptual difference here at all — GIN genuinely IS an
inverted index, using the identical underlying idea.

THE REAL STRUCTURAL DIFFERENCE
------------------------------
Per this chapter, "the real difference is architectural: in Postgres,
GIN is one index type among several (per postgres1-7's own comparison
table — B-tree/GIN/GiST/BRIN/Hash), reached for specifically when
JSONB containment or full-text search is needed, while the rest of the
engine is built around ordinary structured relational data. Here, per
search1-1's own throughline, the inverted index isn't one option among
several — it's the engine's own primary, foundational structure, used
for every field by default unless deliberately configured otherwise."

In Postgres, GIN is a genuinely optional, deliberately-chosen tool —
a developer decides, for a SPECIFIC column (a JSONB column, a
full-text search column), that GIN is the right index type, while
every other column in the same database might use an ordinary B-tree
instead, or no index at all. The relational engine's own primary
machinery (its query planner, its default indexing, its transactional
model) is built around ordinary structured rows, with GIN reached for
as a special-case addition when it's specifically needed.

In Elasticsearch/OpenSearch, per search1-1's own throughline, the
inverted index isn't an optional add-on reached for occasionally —
it's THE engine's own default, foundational structure, applied to
every field of every document automatically (per search1-3's own
dynamic mapping material), unless someone deliberately configures a
field to opt out. There's no equivalent "ordinary structured data,
plus GIN where needed" split here — the inverted index IS the default
way this engine organizes essentially everything.

WHY THIS WORKS AS AN ANSWER
------------------------------
It confirms the underlying concept is genuinely identical (not just
similar) using both chapters' own wording, and explains the real
architectural difference precisely — optional, special-case tool
within a relational engine vs. the engine's own universal, default
foundation — rather than describing the difference only vaguely.