A smaller file can demand a slower scan

A dictionary or delta encoding changes how logical values are represented, while a codec such as Zstandard compresses the resulting page byte stream according to its specified framing. Generic decompression reconstructs those encoded bytes; it does not necessarily produce final Arrow arrays or application objects. Those may require further value decoding, structural reconstruction, conversion, and allocation. Record compressed bytes, decompressed encoded bytes, and fully materialized bytes separately. A claim of several gigabytes per second is uninterpretable if its denominator silently changes between these stages.

Parquet's compression and page-version rules specify exactly which portions are passed to a codec; page headers and structural sections need their own accounting. A reader must not infer that an entire row group is one opaque compressed stream. Codecs and parameters can differ in speed, ratio, memory requirements, and reader support. For Zstandard, the format contract includes frame parameters and bounded decoder requirements, not a promise of one universal throughput. Test representative page sizes, values, and hardware rather than adopting a historical speed ranking as a permanent property of a codec name.

A pipeline can overlap transfer of one page with decompression or query work on another, approaching a throughput determined by the slowest independent stage. That ideal needs enough work, buffers, and genuinely available resources. Two stages competing for the same CPU cores or memory bandwidth cannot both claim their isolated maximum throughput. Startup, tail drainage, small requests, and dependent dictionary loads also matter. Measure the full steady-state pipeline and its peak live memory rather than subtracting costs merely because an API is asynchronous.

For a serialized comparison that otherwise changes nothing, compression helps only if saved transfer time exceeds its extra decode time. The crossover changes when storage bandwidth, cache residency, CPU availability, or query work changes. A training input pipeline may favor a faster decoder to keep accelerators supplied; a cold archive scanned rarely may value reduced storage and transfer differently. Writing and compaction costs also belong in lifecycle evaluation. Preserve lossless semantics and exact result checks while varying parameters so a faster lossy or incompatible representation is not mistaken for an equivalent optimization.

Use the same data, row order, page boundaries, projected fields, predicates, concurrency, and cache conditions when comparing codecs. Report compression time, compressed size, decompression CPU, final query latency, memory, and errors. A file that is much smaller after an expensive rewrite may not repay that rewrite over its actual lifetime. Include difficult data such as high-entropy strings and changing distributions, because easy repeated samples can exaggerate savings. If projected scans touch only a subset of pages, compare that workload rather than claiming a full-file ratio predicts every query.

The roofline instrument demonstrates a separate memory-versus-floating-point ceiling after decoding. Reset, set both I=4 FLOP/byte and memory B=50 GB/s, predict 200 GFLOP/s, then Play or Step. Reset and set both I=32 and B=50, predict the fixed 1,000 GFLOP/s compute cap rather than 1,600, then inspect. Playback traces the selected ceiling; it does not run a codec or measure integer decode throughput. The analogy is that removing one resource limit can expose another, while actual compression choices need the stage-specific measurements above.