# Exercise 2: Diagnosing a Degrading Index

## Scenario

`ShelfSpace`'s on-call engineer pages you with a report: a table called `event_log` (append-only, rows inserted with a monotonically increasing `id BIGSERIAL PRIMARY KEY`, roughly 50,000 inserts/day) has started showing slowly climbing average write latency over the past 3 months — not a sudden spike, a steady drift. A teammate's working theory, based on half-remembered trivia, is: *"B-trees degrade like binary search trees do — inserting sequential IDs must be unbalancing the tree over time, that's why writes keep getting slower. We should switch the primary key to a random UUID to fix it."*

You know from this topic's section 5 and section 6 that this diagnosis conflates two different things: a B-tree's self-balancing guarantee (bounded height, no linked-list degeneration) versus what monotonically-increasing-key inserts actually do to a B-tree (a normal, predictable pattern of right-edge splits, not degeneration).

## Deliverables

Produce all of the following, in this file, below this line:

1. **Correct or refute the teammate's theory**, citing section 5 (splits/merges) and section 6 (why balance matters for disk I/O) explicitly. Be precise about what monotonic-key inserts DO cause (right-edge splits) versus what they do NOT cause (unbounded height growth / linked-list degeneration).
2. **Propose at least two alternative explanations** for genuinely climbing write latency on an append-only table over months, that are NOT about B-tree balance (e.g. table/index bloat from dead tuples, growing total row count naturally lengthening the (still-shallow) tree by one level at some threshold, disk-level factors). For each, state one concrete way to check whether it's the actual cause.
3. **Evaluate the proposed fix** (switching to random UUID primary keys) on its own merits: does it address whatever the real cause turns out to be? What NEW cost does a random (non-sequential) primary key introduce for a B-tree index specifically, reasoning from section 5's insert mechanics (hint: sequential inserts land at the "right edge" predictably; random inserts land unpredictably across the whole tree).

## Constraints

- Do not accept or reject the teammate's theory without an explicit mechanism-level justification tied to a specific section of the theory file — "that's not how it works" alone is not a deliverable.
- Your alternative explanations must be plausible causes of *gradually climbing* latency specifically, not just "the table is big" (a large-but-stable table doesn't explain drift).