Exercise 2: What a BRIN Index Is, Its Small Size, and Its Core Assumption Breaking — Possible Solution
====================================================================

WHAT A BRIN INDEX IS
------------------------------
Per this chapter, "BRIN (Block Range Index) is designed specifically
for very large tables where a column's values have a natural physical
correlation with insertion order — a timestamp column on an
append-only log or events table is the classic case." Rather than
indexing every individual row, "BRIN stores only summary
information — typically the min/max values — for each physical block
range of the table."

WHY IT'S DRAMATICALLY SMALLER THAN A B-TREE
------------------------------
A B-tree index stores an entry for every single row in the table,
which means its own size scales roughly with the number of rows. A
BRIN index, by contrast, stores just one small summary entry (e.g.
the min and max timestamp) per BLOCK RANGE of the table — a group of
many physical pages — not per row. On a table with millions of rows,
this means BRIN needs to store orders of magnitude fewer entries than
a B-tree would, since each entry summarizes a whole range of rows
rather than describing just one. This is exactly why the chapter
calls it "a dramatically smaller index, much cheaper to maintain."

WHY THIS WORKS ONLY WHEN THE CORRELATION HOLDS
------------------------------
The min/max summary per block range is only USEFUL if rows within
each physical block are actually similar in value — which is true
when rows are inserted roughly in order (an append-only log, where
newer timestamps land in newer blocks). If that correlation holds, a
query for "events after date X" can quickly skip over entire block
ranges whose max value is still before X, without inspecting a single
row inside them.

THE WARN-BOX'S OWN GOTCHA
------------------------------
Per this chapter's own warn-box, "if the physical correlation a BRIN
index depends on doesn't actually hold — rows bulk-loaded out of
chronological order, or heavily updated/moved after insertion — a
BRIN index becomes far less effective, and can even make the query
planner's own choices worse than having no index at all, since the
planner may still choose to use a summary index that no longer
reflects reality." If rows with very different values end up mixed
together within the same physical block range (because of an out-of-
order bulk load, for instance), a block range's own min/max summary
stops being a useful filter — nearly every block range might contain
a wide spread of values, meaning BRIN can no longer skip past most of
them, defeating its entire purpose while still costing the planner
time to consider using it.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains BRIN's storage mechanism and size advantage precisely,
using the chapter's own wording, and separately explains the specific
failure mode the warn-box names, including WHY the correlation
assumption is what makes BRIN work in the first place.