Project the columns the whole plan needs

Consider SELECT price FROM events WHERE region='west'. Even though the output has only price, the scan generally needs region to evaluate the predicate unless trustworthy partition or other metadata already establishes it. Joins, grouping keys, sort expressions, and user-defined computations can require further fields. Track the union of required leaf paths so a field used twice is not counted twice. For a nested object, retrieving one child may still need validity or structural information that describes its ancestors; the storage representation determines those dependencies.

After projection, the reader locates column chunks and pages for selected row groups. It can often avoid fetching unrelated field payload entirely, which is a central advantage of columnar layout. But projection does not eliminate file metadata, structural levels, page headers, dictionaries for selected fields, or extra bytes brought in by request coalescing. Large fixed-size remote reads can also deliver neighboring bytes. Record which bytes were requested and which were useful rather than assuming that two selected fields in a ten-field schema always produce exactly one-fifth of the transferred data.

An engine can evaluate selective filter columns first, produce matching row positions, and then fetch or decode other selected columns only where needed. This is late materialization. Its benefit depends on format navigation, engine support, page size, match distribution, and the cost of extra passes. A single matching row may still require decompressing the page containing it. If matches are scattered across every page, a one-percent result can still touch nearly all output-column pages, even while avoiding some value conversion or copying within them.

Page indexes and row-position information help align skips across columns with different page boundaries. They do not make every row independently compressed or randomly accessible at zero cost. Dictionary state may need to be loaded before a referenced data page can be interpreted, and nested fields add structural alignment requirements. Compare an eager scan and a staged scan on both clustered and scattered matches. Include all remote requests, decoder CPU, and intermediate position buffers so the chosen strategy improves the user's operation rather than only one internal counter.

A narrow projection can shift a scan from storage transfer toward decoding, memory bandwidth, or aggregation CPU. Once one layer improves, remeasure before applying the same optimization again. For an AI feature pipeline, unused string columns can be expensive both on storage and in materialized objects, while a compact numeric aggregation can become limited by arithmetic or memory movement. File compression ratio alone cannot diagnose this transition. Use end-to-end latency and per-stage counters with a fixed result check to locate the remaining cost.

The roofline lab concerns a hypothetical floating-point kernel after data has been decoded, not disk throughput or integer decoder speed. Reset, set both intensity I=4 FLOP/byte and memory bandwidth B=50 decimal GB/s, predict a 200 GFLOP/s ceiling, then Play or Step. Reset, re-enter both I=8 and B=50, predict 400 GFLOP/s, then inspect. The compute roof stays 1,000 GFLOP/s and playback only traces the roof. Projection may change a real kernel's bytes per useful operation, but the lab does not project a file or measure a scan.