Exercise 2: The "Index" Terminology Collision — Possible Solution
====================================================================

WHAT "INDEX" MEANS IN ELASTICSEARCH/OPENSEARCH
------------------------------
Per this chapter, "an index is the closest analog to a 'table,' or
arguably a whole 'database.'" In this course, an index (created via
something like PUT /products) is the PRIMARY CONTAINER that documents
actually live inside — comparable to a MySQL/Postgres table, or a
MongoDB collection. It's the top-level organizational unit data is
grouped into, not a secondary structure.

WHAT "INDEX" MEANS IN MYSQL/POSTGRES
------------------------------
In MySQL and Postgres — per this site's own postgres1-7 material — an
index (a B-tree, a GIN index, and so on) is a SECONDARY data structure
built ON TOP of an already-existing table, specifically to speed up
certain kinds of queries against that table's own data. A MySQL/
Postgres table can exist and hold real data with zero indexes defined
on it at all — the index is an optional performance optimization
layered onto a table that already has its own independent existence.

WHY THIS IS A GENUINE TERMINOLOGY COLLISION
------------------------------
The exact same English word — "index" — refers to two structurally
DIFFERENT things in these two contexts: in Elasticsearch/OpenSearch,
it's the primary container itself (comparable to a table); in MySQL/
Postgres, it's a secondary structure built to speed up queries against
an already-existing table. Per this chapter, "here, 'index' IS the
primary container itself... not a secondary structure built on top of
one." Someone arriving from mysql1/postgres1's own material could
naturally, but wrongly, assume that "creating an index" in
Elasticsearch/OpenSearch means something analogous to CREATE INDEX in
SQL (adding a performance structure to existing data), when it
actually means something much closer to CREATE TABLE.

WHY GETTING THIS RIGHT MATTERS
------------------------------
Misunderstanding this specific vocabulary collision would lead to a
fundamentally wrong mental model of how Elasticsearch/OpenSearch is
actually organized — mistaking the primary data container for a mere
performance add-on would make basic operations (like PUT /products to
create a new "index") genuinely confusing, since the learner would be
expecting to first need some other, separate concept to hold the data
that the "index" is merely speeding up access to. Clarifying this
immediately, before any real usage, avoids that entire category of
confusion for every later chapter.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines "index" precisely in both contexts using the chapter's own
wording and postgres1-7's own established material, and explains the
concrete confusion this collision could otherwise cause for someone
transferring assumptions directly from the site's own SQL-based
courses.