Choose a representative workload

01 / Describe the customer

A workload is more than a dataset size

A workload combines the data with the requests made against it. Its description includes how many records exist, which values are common, which queries arrive, how often they arrive, and which responses matter. A trace is an ordered list of requests. A replay executes that list so another person can repeat the same work.

Our starting workload has two jobs: an unindexed lookup of the midpoint order, and an aggregation that sums revenue into month-and-region groups. The lookup returns one row. The report reads all orders and returns up to 48 groups. Keeping those jobs separate makes an important tradeoff visible: an option can perform differently for an interactive lookup and a report that scans many rows.

Distribution means how values are spread across the data. With uniform regions, orders are evenly assigned to four regions. With a hotspot, nine of every ten rows are assigned to region 1; the remaining rows cycle through regions 2, 3 and 4. This creates exactly 90% in region 1 for our bounded sizes. These synthetic patterns make a condition reproducible. They are hypotheses to test against customer evidence, rather than a claim to represent every business.

The final three rows are deliberate limitations. A repeated midpoint lookup can benefit from warm state. A sequential trace cannot establish performance under a busy hour. Chapter 5 examines the runner; later demand exercises add arrival rates and concurrency. A useful early report keeps the missing dimensions visible.

02 / A worked calculation

A recommendation depends on the mix

Before running, use an explicitly invented arithmetic example. Suppose option A takes 1 ms for a lookup and 8 ms for a report; option B takes 3 ms and 4 ms. These are teaching numbers, not observations from either database.

80% lookups:
A = 0.8 × 1 + 0.2 × 8 = 2.4 ms/request
B = 0.8 × 3 + 0.2 × 4 = 3.2 ms/request

20% lookups:
A = 0.2 × 1 + 0.8 × 8 = 6.6 ms/request
B = 0.2 × 3 + 0.8 × 4 = 3.8 ms/request

A has the lower weighted value in the lookup-heavy scenario; B has the lower one in the report-heavy scenario. The weights changed while the class times stayed fixed. That calculation helps explain a business choice, but a mean hides individual response requirements. If the order screen must respond within a target, inspect lookup results directly even when the mix summary looks good.

The live exercise uses medians, the middle measured value in each request class, as inputs to a weighted planning summary. A weighted combination of class medians is neither the median of the whole trace nor a measurement of concurrent capacity. The actual request times and the actual trace sum remain available alongside it.

03 / Replay real SQL

Change one workload condition

Begin with the defaults and download the record. Keep the size and distribution fixed, change only the request mix, and run again. Then hold the mix fixed and change distribution or size. The deterministic trace spaces lookup requests through ten positions; it does not silently generate a new random order on each run.

CREATE TABLE orders (order_id INTEGER, month_id INTEGER,
 region_id INTEGER, amount_cents INTEGER);
SELECT order_id, month_id, region_id, amount_cents
FROM orders WHERE order_id = 1000;
SELECT month_id, region_id, CAST(SUM(amount_cents) AS BIGINT)
FROM orders GROUP BY month_id, region_id ORDER BY month_id, region_id;
-- The download contains the deterministic generator and full INSERT statements.

04 / Interpret a workload result

Separate a mix effect from a data effect

First check that every answer passed. Read lookup and report medians individually, then inspect each raw request. With only two samples in a minority class, its median is fragile. A small gap or an unexpected reversal needs repeated independent runs; it does not justify a sweeping recommendation.

If you change only the mix, a weighted summary may change because you counted one job more often. The engines also see a different request sequence, which can affect their warm state. To isolate arithmetic weighting, recompute both weights from the same saved class times. To assess the full workload, replay both traces and retain both records. Those are related but different experiments.

Changing the region distribution changes the report's groups and the midpoint row's region. The independent reference is regenerated from the actual rows, so both engines must return the correct answer for that fixture. A hotspot does not guarantee a performance reversal: the SQL still scans all rows, these datasets are small, and browser request overhead can dominate. “No clear change in these runs” is a useful observation when accurately bounded.

05 / Independent practice

Replace a convenient workload with a justified one

Write a workload brief for an order-screen customer and a month-end reporting customer. Choose which shipped trace is closer to each, state why, and list the evidence you would need before using that choice in a sales comparison. Avoid using confidential customer rows; aggregated frequency counts often establish the first design.

1. Run two mixes with the same data. Record a finding for each job and explain the weighted calculation.
2. Change one data condition and run again. State what did and did not change within your observations.
3. Design a new ten-request trace with a short report burst. Predict which conclusion it might challenge, then implement and execute it locally.

For that final step, edit trace() in src/methods-model.ts. For example, return eight 'lookup' entries followed by two 'revenue' entries. A quoted word here is a request-class name; the runner uses it to select SQL and the independent expected answer. Keep the total at ten and keep the selected mix consistent with its counts, so the weighted summary remains truthful. Then use the local reproduction commands and compare your burst trace with the evenly interleaved baseline.

Notes and selected controls save locally on this device when storage is available. Each export includes your current notes with the original completed settings.

06 / Sources and reproducibility

Keep the workload attached to the score

The deterministic generator is the Chapter 2 generator. In hotspot mode, rows whose zero-based offset is not divisible by ten are assigned to region 1; every tenth row cycles through regions 2, 3 and 4. A separate JavaScript reference scans the resulting rows and calculates every expected result. Both engines load identical INSERT statements, gather statistics with ANALYZE, and use the same SQL. No query timing is simulated.

• DuckDB-Wasm overview and PGlite documentation describe the execution environments.
• TPC benchmark specifications illustrate why a benchmark defines its data, transactions, scaling and reporting rules together. This exercise is not a TPC result.
• Measurement contract and local reproduction; engine source and licence notices.

Next, investigate whether the program sending these requests is itself limiting or distorting the observation.