Chapter 28 — Quiz

13 questions. Answers at the bottom.

Multiple choice

Q1. PostgreSQL's page (block) size is: - A) 1 KB - B) 4 KB - C) 8 KB - D) 1 MB

Q2. The heap is: - A) An index structure - B) The collection of pages holding a table's rows - C) The buffer pool - D) The WAL

Q3. TOAST handles: - A) Small integers - B) Oversized attribute values (large text/jsonb/bytea) - C) Indexes - D) Transactions

Q4. The buffer pool is: - A) Disk storage for backups - B) An in-memory cache of recently-used pages - C) The WAL - D) A lock table

Q5. A query is slow the first time and fast the second because: - A) The optimizer learns - B) The pages are now cached in the buffer pool (warm cache) - C) Indexes were added - D) Statistics updated

Q6. The write-ahead rule says: - A) Write data pages before the log - B) Write the WAL record (and flush) before modifying the data page - C) Never write the log - D) Write everything at COMMIT only

Q7. Durability after a crash is achieved by: - A) Re-running queries - B) Replaying the WAL from the last checkpoint - C) Restoring a backup always - D) MVCC

Q8. An UPDATE under MVCC: - A) Overwrites the row in place - B) Writes a new version and marks the old one dead - C) Locks the whole table - D) Deletes the row

Q9. Dead tuples are reclaimed by: - A) Indexes - B) VACUUM / autovacuum - C) Checkpoints - D) The WAL

Q10. A long-running transaction causes bloat because: - A) It uses too much CPU - B) It holds an old snapshot, so VACUUM can't remove dead tuples newer than it - C) It locks all tables - D) It disables autovacuum

Q11. A DELETE immediately: - A) Returns space to the OS - B) Marks tuples dead; VACUUM later makes the space reusable - C) Rewrites the table - D) Drops the table

True/False

Q12. The WAL is also the basis for replication and point-in-time recovery. (True / False)

Q13. VACUUM FULL is a routine, lightweight operation you should run constantly. (True / False)

Short answer

Q14. Explain, using internals, why indexes speed reads but slow writes.

---

Answer key

Q1 — C. 8 KB.

Q2 — B. The pages that hold a table's rows.

Q3 — B. Oversized values (compressed/out-of-line).

Q4 — B. In-memory page cache (shared_buffers).

Q5 — B. Warm cache: pages now in the buffer pool.

Q6 — B. WAL first (flushed), then the data page.

Q7 — B. Replay the WAL from the last checkpoint.

Q8 — B. New version + old marked dead (MVCC).

Q9 — B. VACUUM/autovacuum.

Q10 — B. Its old snapshot keeps dead tuples "still visible," so VACUUM can't reclaim them → bloat.

Q11 — B. Marks dead; VACUUM reclaims the space for reuse (only a rewrite returns it to the OS).

Q12 — True. The WAL is the complete change record; replicas replay it, and PITR uses it.

Q13 — False. VACUUM FULL rewrites the table under an exclusive lock — heavy and occasional, not routine.

Q14. A read using an index touches fewer pages (walk the small, sorted index to the few matching heap pages) instead of scanning all the table's pages — fewer page reads, faster. But every INSERT/UPDATE/DELETE must also update every index on the table (more pages modified, more WAL written) — so each index adds write work. Reads touch fewer pages; writes touch more. That's the trade.

Scoring: 12–14 you understand the why behind Part IV; 9–11 review WAL and VACUUM; below 9, do the hands-on exercises (B, D).