> > If we expect fields nested in structs to always be much slower than flat > fields, then I would be keen to address that in our ETL pipeline with a > flattening step. If it's a known issue that we expect will be fixed in > upcoming releases, I'll hold off. >
The difference might be even larger in Spark 2.0 (because we really optimize the simple case). However, I would expect this to go away when we fully columnarize the execution engine. That could take a while though.
