A reporting script on a laptop pulls all 40 million rows of the sales table across the network and then sums revenue by region in memory. It is slow and saturates the network link. What is the best fix?
Select an answer to reveal the explanation.
Short Explanation
Why haul the whole warehouse home just to count the boxes? Let the database do the GROUP BY right where the data lives, and you get back a handful of totals. The trap is any answer that makes the hauling faster instead of stopping it.
Full Explanation
Data-intensive work belongs where the data is. A single statement such as SELECT region, SUM(revenue) FROM sales GROUP BY region lets the database engine read the table locally, use indexes or parallelism where available, and return one row per region. The network then carries a few rows instead of 40 million, and the laptop does almost no work. This is the core principle behind choosing the runtime location of a script: client-side processing makes sense for presentation and light logic, while aggregation over large datasets should run on the server. Adding memory to the laptop addresses only the in-memory step; every row still crosses the network, so the link remains saturated and the job remains slow. Compressing the transfer reduces bytes somewhat but still moves the full dataset and adds compression work at both ends, treating the symptom rather than the design. Splitting the pull into batches limits peak memory use but transfers exactly the same volume of data in total, so network load and elapsed time do not improve. Exam caveat: pushing work to the server shifts load onto the database, so heavy aggregations on a busy OLTP system may belong on a replica or reporting copy. Operational check: run the aggregate query on the server, compare its totals with the script's output, and confirm both the rows transferred and the elapsed time drop sharply.