{"id":"dee43d47-6ed0-497a-b817-4049ed4f9566","arxiv_id":"2602.17335","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"CPU-oriented Parquet defaults, not the format itself, bottleneck GPU scans; GPU-aware rewriting raises effective bandwidth to 125 GB/s.","lead":"Parquet files are usually written with CPU-friendly settings, and this paper shows those settings — not the format itself — are what slow down GPU scans. Rewriting Parquet files with GPU-aware settings raises effective read bandwidth to 125 GB/s without changing the file format.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Insight 1 rests on an unverified claim about cuDF's page-to-grid mapping; if that mapping is wrong, the page-count rule and part of the 125 GB/s gain do not transfer.","rationale":"The paper is internally consistent and the measurements are transparent, but the central claim that Parquet configurations, not the format, explain GPU scan bottlenecks depends on four insights. The weakest link is Insight 1, which rests on an unverified claim about how cuDF maps pages to kernel grid size. The reader's weakest_assumption identified exactly this. Unlike the representativeness concern or the lack of error bars, this is not just about statistical scope: if the page-to-grid mechanism is wrong, the first and most fundamental recommended configuration (page count >= 100) loses its stated justification, and the causal story for why the baseline is slow collapses. The measured effect might still exist on PystachIO, but the paper generalizes beyond that system. A direct source inspection or a standalone cuDF microbenchmark would settle whether the mechanism is real. I therefore agree with the reader's conditional verdict and see no reason to change it; the paper should remain CONDITIONAL until the engine-mechanics claim is verified. I did not find evidence of internal contradiction or derivational circularity, and the effective-bandwidth metric is explicitly defined, so I do not treat the compression-ratio inflation as a fatal issue.","tokens_in":6809,"tokens_out":5333,"duration_ms":51057,"concrete_test":"Run the same Parquet rewrite (page count 1, 100, 400; row-group size fixed at 10M rows) through unmodified cuDF's Python API on TPC-H SF300 lineitem, bypassing PystachIO, and measure end-to-end decode time. If throughput is flat across page counts, Insight 1 is an artifact of PystachIO's kernel launch configuration; if throughput increases with page count up to the recommended grid size, the rule holds for cuDF-style readers.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's first and most consequential insight is: 'cuDF maps the number of pages to the grid size in its GPU kernel launch parameters' (Section 3, 'Increase Page Count'). No citation, code reference, or version is given, and all experiments use PystachIO, the authors' own reader layered on cuDF. If this mapping is not actually how cuDF launches decode kernels, or if it changes across cuDF versions, then the recommended page-count >= 100 has no mechanical basis, and the contribution of Insight 1 to the 125 GB/s headline is not generalizable. The concern is not that the measured curves are wrong on the tested stack; it is that the claimed causal mechanism is an unsupported engine-specific premise. A different GPU Parquet reader that parallelizes by column chunk or row group, or uses a fixed grid, would not benefit from this rule, so the central claim that Parquet's poor GPU performance is a config problem rather than a format problem would lose a key pillar.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper investigates whether Parquet's poor GPU scan performance is inherent to the format or caused by CPU-oriented configuration defaults. Using PystachIO (the authors' GPU query engine on cuDF), an A100, and TPC-H SF300 lineitem read from local SSDs via GPUDirect Storage, the authors report four configuration insights: (1) page count per row group should be at least 100; (2) row-group sizes of millions of rows are preferred; (3) per-column-chunk encoding selection should choose the smallest encoded size; (4) compression should be skipped when size reduction is below a threshold (10% in their experiments). They contribute a Parquet rewriter tool and report an effective read bandwidth of up to 125 GB/s from four SSDs without modifying the Parquet specification. The central claim is that Parquet's poor GPU performance is a configuration problem, not a format problem.","tokens_in":6907,"tokens_out":5042,"duration_ms":44518,"significance":"If the results hold, the paper provides concrete and immediately actionable configuration guidance for GPU Parquet reads and establishes a baseline for evaluating new GPU-oriented file formats. The paper is honest about the limited impact of compression-skipping, which helps only at four SSDs in their setup, and it ships a rewriter tool that is directly reusable. The insights are stated as configuration rules rather than fitted to the measured data, which is a strength. The main limitation is external validity: all experiments use one dataset, one GPU, and the authors' own engine, and the key mechanism in Insight 1 rests on an unverified cuDF implementation detail. Nevertheless, the paper is a useful empirical contribution provided the mechanism claim is substantiated or appropriately scoped.","major_comments":[{"comment":"The premise that 'cuDF maps the number of pages to the grid size in its GPU kernel launch parameters' is stated without citation, code reference, or cuDF version. This is the causal basis for Insight 1 and part of the reported 125 GB/s gain. Because all experiments are run with PystachIO, the authors' own reader layered on cuDF, the reader cannot distinguish a cuDF-wide property from a PystachIO-specific design choice. If other GPU Parquet readers (e.g., Theseus, Sirius, Velox-cuDF) parallelize by row group or column chunk, the page-count rule may not transfer. Please add a cuDF source/version citation or reframe Insight 1 as an empirical finding on this stack, and discuss portability.","section":"Section 3, 'Increase Page Count'"},{"comment":"The evaluation covers a single dataset (TPC-H SF300 lineitem), a single GPU (A100), and a single engine (PystachIO). The contributions claim 'first guidance on optimizing Parquet for GPU databases,' and Insights 2 and 3 are stated generally. However, Insight 2 (million-row RGs) is tied to GDS saturating this SSD configuration, and Insight 3 depends on the data distribution of one table. To support the central claim that Parquet's poor GPU performance is a configuration problem rather than a format problem, at least one additional dataset and ideally a second reader should be tested; otherwise, the scope of the conclusion should be explicitly narrowed.","section":"Section 3 and Section 4"},{"comment":"Insight 4 says 'Skip unnecessary compression if no size reduction,' but the implemented rule is 'only when its size reduction exceeds a chosen threshold (10% in our experiments).' The two statements are inconsistent. Since the measured gain is confined to the four-SSD configuration, the choice of threshold is not innocuous; without a sensitivity analysis or a justification for the 10% threshold, the insight is underdetermined.","section":"Section 3, 'No Unnecessary Compression'"}],"minor_comments":[{"comment":"The annotation '125x' is confusing; it likely means '125 GB/s' or '125x improvement' but is not explained in the caption or text.","section":"Figure 1"},{"comment":"The metric changes from 'storage bus bandwidth' in Figure 2 to 'effective bandwidth' in Figure 3. The text explains the change, but the figures should label the metric consistently, and both metrics should be defined in a single place.","section":"Figure 2 vs. Figure 3"},{"comment":"Reference [24] cites a general Hadoop book rather than the Apache Parquet format specification. Please cite the official specification for the format definitions used in Section 2.","section":"References"},{"comment":"The rewriter is available via a URL but no version or commit hash is given. Including a specific version would improve reproducibility.","section":"Rewriter tool availability"},{"comment":"The choice of page count 100 is described as 'reasonable' and tied to the kernel grid size, but no occupancy analysis or A100 grid limits are provided. A brief note would help justify the selected value.","section":"Section 3, 'Increase Page Count'"}],"recommendation":"major_revision","confidential_remarks":"This is a short empirical paper with a clear practical message. The main risk is the unsupported cuDF mechanism claim in Insight 1, which is load-bearing for the headline result. I would request a revision that either substantiates the mechanism with a cuDF source/version or explicitly limits the claim to PystachIO/cuDF. The use of the authors' own engine in the evaluation is a concern, but not disqualifying if the claims are scoped appropriately."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper makes a modest but genuinely useful point: on a cuDF-based GPU stack, Parquet's poor scan performance is largely a configuration problem, not a format problem. The authors show that raising page count, increasing row-group size, allowing per-chunk encoding choice, and skipping useless compression gets them to 125 GB/s effective bandwidth on TPC-H SF300 lineitem without touching the Parquet spec. I believe the measurements as point estimates on their stack. They report honestly where the tricks stop helping (compression skipping only matters at four SSDs) and they ship a rewriter tool, which counts for a lot.\n\nWhat's actually new is the systematic evaluation of Parquet configuration choices for GPU scans. Three of the four insights echo published work they cite (GDS transfer sizing, BtrBlocks-style encoding selection, decompression-vs-I/O tradeoff), but the page-count-to-grid interaction is new, and the combined config recipe is a useful baseline for anyone comparing GPU-native formats. The paper is clearly written and does not oversell its generality beyond the stack it tests.\n\nThe soft spots are real but not fatal. There are no error bars or trial counts, everything is validated on one table, one GPU, one engine (their own PystachIO), and the configuration values are tuned on the same workload used to demonstrate the gains. The biggest concern, which the stress-test flags, is Insight 1's mechanism: the claim that cuDF maps page count to the GPU kernel grid size is stated without citation or version check. If that mapping is wrong or changes, the page-count rule loses its mechanical basis. But the empirical curve in Figure 2(a) stands on its own, and the paper is framed as what works on this stack, so I would not call this a load-bearing flaw—just a gap that a revision should close with a pointer to cuDF source or a version check.\n\nThe paper would benefit from a second dataset and a second reader (even a CPU reader for comparison), and from error bars. Those are reasonable referee asks, not reasons to reject. The central argument—that configuration, not format, explains most of the GPU Parquet gap on this system—holds up.\n\nThis is a paper for GPU analytics researchers and engineers deciding whether to invest in new file formats. It deserves a serious peer review. I'd send it out, with the expectation of moderate revision.","headline":"A useful, honest config-tuning study for GPU Parquet scans; the central claim holds on the tested stack, but the page-count mechanism is under-supported and generality is untested.","tokens_in":7529,"tokens_out":1855,"would_cite":true,"duration_ms":19229,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Parquet's GPU slowness is a configuration problem, not a format flaw.","keywords":["Parquet","GPU data processing","columnar file formats","scan performance","file configuration","data compression","GPUDirect Storage","TPC-H"],"falsifier":"Measure a GPU Parquet scan with page counts below 100 on a different GPU Parquet reader that does not map pages to the kernel grid; if bandwidth does not drop as the paper's Figure 2(a) shows, the page-count insight is engine-specific, not a property of the format configuration. Alternatively, run the same four-configuration rewrite on a second table and on a different GPU architecture and check whether 125 GB/s still holds.","tokens_in":6563,"feed_emoji":"⚡","tokens_out":4388,"duration_ms":37603,"temperature":0.7,"pith_summary":"This paper argues that GPU scans of Parquet files are slow not because of the format's design but because Parquet's standard configuration defaults were tuned for CPUs. On an NVIDIA A100 reading TPC-H data from SSDs via direct GPU storage, the authors show that four configuration changes—raising page count to at least 100, enlarging row groups to millions of rows, choosing the smallest per-chunk encoding, and skipping compression when it shrinks data less than 10%—raise effective read bandwidth to 125 GB/s. All changes stay within the existing Parquet specification, so no new file format is required. The claim matters because GPU-accelerated analytics systems currently spend most of their time in Parquet scans, and the fix is a one-time file rewrite rather than an ecosystem-wide format migration.","feed_headline":"Four config tweaks push Parquet GPU scans to 125 GB/s","feed_subtitle":"A one-time file rewrite fixes GPU scan slowdowns without changing the Parquet specification.","key_machinery":"The central mechanism is the configuration knobs of the Apache Parquet format themselves, reinterpreted for GPU execution. The paper maps each knob to a GPU-engine behavior: page count becomes the GPU kernel grid size in the reader's decoder; row-group size determines column-chunk I/O size for direct storage reads; per-chunk encoding flexibility leverages local data distribution to minimize encoded size; and compression selectivity avoids compute-bound decompression. The accompanying Parquet rewriter tool applies these four rules as an offline preprocessing step, transforming existing CPU-default files into GPU-tuned ones.","core_discovery":"The paper's central claim is that Parquet's poor GPU performance is not inherent to the format but a consequence of suboptimal configuration choices made by CPU-oriented writers. Specifically, it identifies four configuration insights: (1) page count should be 100 or above so the GPU reader's decoding kernel maps pages to the GPU grid and fully utilizes the device; (2) row-group sizes of millions of rows produce column chunks large enough for direct storage reads to saturate SSD bandwidth; (3) allowing each column chunk to pick among Parquet V1 and V2 encodings and keeping the smallest result improves effective bandwidth; and (4) skipping compression when it reduces chunk size by less than 1","pith_inferences":["It follows, though the paper does not test it, that the 125 GB/s figure likely varies by GPU architecture and reader implementation: the page-count rule is tied to the specific reader's current kernel-launch mapping, so other GPU Parquet readers or future versions may need different page counts.","Treating the TPC-H lineitem table as representative is a bet; a wider evaluation across different schemas and data distributions would test whether the four rules generalize.","A testable extension is to benchmark the rewriter's output against a GPU-native format on the same SSD+A100 stack; the paper's claim would be strengthened if optimized Parquet remains competitive.","The compression threshold of 10% and page-count threshold of 100 are presented as reasonable choices, not optima; a search over thresholds could find small additional gains."],"forward_implications":["GPU-accelerated databases can get up to 125 GB/s effective scan bandwidth by rewriting Parquet files with these four rules, without waiting for a new file format.","This gives a strong, realistic baseline against which any proposed GPU-native format must be measured—the new format must beat an already-optimized Parquet read from SSDs.","The rewriting is a one-time offline step that typically completes within minutes for 100 GB datasets, and since files often shrink, storage overhead need not increase.","The two I/O-related insights (page count, row-group size) are specific to GPU stacks, while the encoding and compression insights also apply to CPU systems and are already being discussed in the wider Parquet ecosystem."],"fun_headline_variants":["Parquet not the problem: GPU-unaware config is","Four config tweaks push GPU reads to 125 GB/s","125 GB/s GPU scans without changing Parquet format","Stop blaming Parquet—reconfigure it for GPUs instead"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The whole result rests on the premise that the GPU Parquet reader really maps page count to GPU kernel grid size; if a reader parallelizes differently, the page-count rule and its measured bandwidth gains do not transfer.","fun_headline_variants_meta":{"raw":{"variants":["Parquet not the problem: GPU-unaware config is","Four config tweaks push GPU reads to 125 GB/s","125 GB/s GPU scans without changing Parquet format","Stop blaming Parquet—reconfigure it for GPUs instead"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000579,"raw_usage":{"total_tokens":2504,"prompt_tokens":623,"completion_tokens":1881,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":367,"completion_tokens_details":{"reasoning_tokens":1813}},"tokens_in":367,"tokens_out":1881,"duration_ms":14276,"temperature":1.0,"reasoning_tokens":1813,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-02T22:14:46.907879+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure a GPU Parquet scan with page counts below 100 on a different GPU Parquet reader that does not map pages to the kernel grid; if bandwidth does not drop as the paper's Figure 2(a) shows, the page-count insight is engine-specific, not a property of the format configuration. Alternatively, run the same four-configuration rewrite on a second table and on a different GPU architecture and check whether 125 GB/s still holds.","supporting_citations":[],"review_version":1}