Research Question & My Role
My COMP 418 paper investigated Azure SQL wait statistics and possible responses. This retrospective is rewritten from scratch and excludes the original operational measurements, database identifiers, screenshots, embedded material, and assignment questions.
Method
The study collected cumulative waits, researched their categories, and proposed interventions. It did not change the database or test the result of a tuning decision.
Findings
The useful result was a set of hypotheses about shared costs from query shape, reads, memory, parallel work, and client consumption. The paper did not demonstrate a performance improvement or prove that one remedy would work.
Limits of the Evidence
Cumulative waits are a starting point, not elapsed downtime: concurrent tasks, resets, observation windows, and workload changes affect totals. The original explanations also need correction. PAGEIOLATCH concerns page I/O latches rather than transaction locks, and ASYNC_NETWORK_IO can reflect slow client consumption rather than a distributed commit vote.
What I Take Into Engineering
I would now separate observation, explanation, and demonstrated improvement more sharply. The newer systems note linked below develops that method and links waits to a defined interval, workload, and user-visible symptom.
What I Would Test Next
A follow-up should compare wait deltas, plans, resource behaviour, result correctness, write overhead, concurrency, and user-visible latency under comparable load. AI was not part of the study; a future assistant could cite observations and uncertainty, but should not change indexes or configuration from a wait label alone.