Exercise 1: Why the Pool Counts Alone Can't Distinguish the Two Causes — Possible Solution
====================================================================

WHAT THE COUNTS ACTUALLY SHOW
------------------------------
"Active: 20, waiting: 14" only shows how many connections are
currently in use and how many requests are blocked waiting - a
snapshot of quantity, not of how long any individual connection has
been held.

WHY BOTH CAUSES PRODUCE THE IDENTICAL COUNTS
------------------------------
Per this chapter, "the active/idle/waiting counts alone can't
distinguish the two - both look identical from that view alone." A
pool that's genuinely undersized under high concurrent traffic (many
short-lived connections) and a pool being starved by a few
long-held connections can both end up with all 20 connections active
and 14 requests waiting - the raw counts don't reveal which situation
produced that state.

WHAT ACTUALLY DISTINGUISHES THEM
------------------------------
Per this chapter, "what actually separates them is how long connections
are being held" - genuine capacity shortage involves many connections
each held briefly; a starved pool involves a small number of
connections held for seconds or minutes while everything else is
normal. This information (duration) isn't visible in a simple
active/idle/waiting count at all - it requires checking hold time
specifically, which is why this chapter turns to pg_stat_activity/
SHOW PROCESSLIST next.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains what the counts do and don't capture, and identifies the
specific missing dimension (connection hold duration) that the counts
can't show but is required to tell the two causes apart.