Does iceberg support "Predicate Pushdown" when spark read data from it?

[Akeron-Zhu]

I had run same SQL use spark-3.3, the only difference is data source，one is hive and another is iceberg。The web UI show that, however, iceberg read all table (e.g, 1.1TB), but hive read much less than iceberg (e.g, 40GB). I guess the reason is hive can prune data through the predicate pushdown and iceberg don't support it, is this right?

[RussellSpitzer]

Depends on the query, there are some finicky details there but sometimes (especially in early versions of Iceberg and Spark) predicates don't translate correctly.

Iceberg does support Predicate Pushdown, the rules are just slightly different but in general if the types match up correctly everything should be exactly the same.

[Akeron-Zhu]

Depends on the query, there are some finicky details there but sometimes (especially in early versions of Iceberg and Spark) predicates don't translate correctly.

Iceberg does support Predicate Pushdown, the rules are just slightly different but in general if the types match up correctly everything should be exactly the same.

Thanks for your answer. I read Spark 3.3.3 source code after I encounter this problem and find that there is a special hive client in the code, the special hive client also has a special rule named PruneHiveTablePartitions which used to prune hive table partitions. Does iceberg support prune partitions or any rule like this?

[nateagr]

Hello!

I'm also interesting in more details about the predicate pushdown in Iceberg. I've opened an issue about it here. I have experienced the same issue as described by @Akeron-Zhu . With predicates as simple as ((int) column > (int) X), I have noticed a significant slowdown when reading one of my Iceberg tables with Spark in comparison to reading a simple parquet table from Hive that has exactly the same schema.