https://hackerpaper.kaipfister.de/p/2504.11540/Collected HN comments and submissions linking this paper.enMon, 02 Nov 2026 11:16:22 GMThttps://news.ycombinator.com/item?id=46722533urn:hackerpapers:submission:2504.11540:46722533Thu, 22 Jan 2026 17:39:23 GMT<p>Pruning in Snowflake: Working Smarter, Not Harder</p><p></p><p>1 point; 0 discussion replies on HN. <a href="https://hackerpaper.kaipfister.de/p/2504.11540/">Paper and source history</a>. A submission is not an endorsement.</p>cs.DBhttps://news.ycombinator.com/item?id=45833151urn:hackerpapers:mention:2504.11540:45833151Thu, 06 Nov 2025 09:23:20 GMT<p>I have to very much disagree on that. All pruning techniques in Snowflake work equally well both on their proprietary format as well for Iceberg tables. Iceberg is nowadays a first-class citizen in Snowflake, with pruning working at the file level, row group level, and page level. Same is true for other query optimization techniques. There is even a paper on that: https://arxiv.org/abs/2504.11540 Where pruning differences might arise for Iceberg tables is the structure of Parquet files and the availability of metadata. Both depend on the writer of the Parquet files. Metadata might be…</p><p><a href="https://hackerpaper.kaipfister.de/p/2504.11540/">Paper and discussion history</a>. A mention is not an endorsement.</p>cs.DB