<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Emr on Dustin Smith's Online Resume</title><link>https://dustinsmith.info/tags/emr/</link><description>Recent content in Emr on Dustin Smith's Online Resume</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 10 Aug 2026 01:30:00 +0700</lastBuildDate><atom:link href="https://dustinsmith.info/tags/emr/index.xml" rel="self" type="application/rss+xml"/><item><title>Your Parquet Column Indexes Are Being Ignored on EMR and Glue</title><link>https://dustinsmith.info/blog/aws-parquet-column-index/</link><pubDate>Mon, 10 Aug 2026 01:30:00 +0700</pubDate><guid>https://dustinsmith.info/blog/aws-parquet-column-index/</guid><description>&lt;p>I was benchmarking data-clustering layouts on Delta tables. Locally, everything was skipping beautifully, box queries touched about 10% of rows. Then I ran the identical benchmark on EMR 7.13 and those queries scanned 93% of the table. Same code, same data shape, same queries.&lt;/p>
&lt;p>Either my layouts were broken on EMR, or something in the read path was. This is the investigation that followed. It ends with a four-environment A/B test proving that the AWS Spark runtime&amp;rsquo;s vectorized parquet reader, on both EMR 7.13 and Glue 5.0, performs row-group pruning but &lt;strong>never applies parquet column indexes&lt;/strong>. Stock Apache Spark 3.5.6, the exact version EMR ships, applies them fully against the same files.&lt;/p></description></item></channel></rss>