Exercise 2: What Seq Scan Means and Why It's a Red Flag on Large Tables — Possible Solution
====================================================================

WHAT Seq Scan MEANS
------------------------------
Per this chapter, "Seq Scan means the database read through the entire
table... to find one matching row - because no index exists on the
column being filtered." Rather than jumping directly to the matching
row(s), the database has to check every single row in the table one by
one to find the ones that match the query's filter condition.

WHY THIS IS FINE ON A SMALL TABLE
------------------------------
Reading through every row of a small table (a few hundred or thousand
rows) is cheap and fast regardless of whether an index exists, since
there's simply not much data to scan through - a sequential scan on a
small table can even be faster than using an index, in some cases.

WHY IT'S A GENUINE RED FLAG ON A LARGE TABLE
------------------------------
Per this chapter's own example, the Seq Scan example scanned "2.5
million rows" to find one match, taking over 810ms - compared to an
Index Scan on the same shape of query taking 0.016ms, "over 50,000
times faster." As a table grows, a sequential scan's cost grows
proportionally with the table size, while an index scan's cost stays
roughly constant regardless of table size - so the larger the table,
the more dramatically a missing index costs in real query time.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the specific mechanism (reading every row vs. jumping
directly to matches) rather than just naming Seq Scan as "bad," and
explains why table size specifically determines how severe the cost
actually is, using the chapter's own concrete numbers.