我在S3上使用AWS Athena查询镶木地板数据时遇到了这个奇怪的问题。基本上，我有一个parquet文件(大约38MB(存储在S3上，具有以下模式：
表名：test_Table_tinyint
- ntwk_id(int(
- broadcast_date(字符串(
- daypart_id(tinyint(
然后我运行以下查询：从"test_table_tinyint"中选择count(*(，其中daypart_id=5；
结果：运行时间：2.7秒，扫描数据：32MB
这很奇怪，因为它看起来并没有利用镶木地板文件中的列索引，而是实际进行了一次完整的表扫描。
然后作为比较，我创建了另一个具有相同数据但略有不同模式的表：
表名：test_Table_int
- ntwk_id(int(
- broadcast_date(字符串(
- daypart_id(int(
从"test_table_int"中选择count(*(，其中daypart_id=5；
这次我得到了一个更好的结果：
运行时间：1.07秒，扫描数据：326.49KB
我在Spark with Spark SQL中遇到了类似的问题，看起来拼花文件中的TinyInt列会导致完整的表扫描。如果我将文件转换为ORC格式，那么AWS Athena和Spark SQL在"TinyInt"one_answers"Int"中都得到了类似的结果
有什么想法吗？
感谢
这是因为当daypart_id是TINYINT时，daypart_id = 5实际上是CAST(daypart_id AS INTEGER) = 5(强制类型从窄到宽(。
为了防止强制发生并干扰下推，可以给5常量和显式类型：daypart_id = TINYINT '5'。
注意：我几乎可以肯定，新版本的Presto已经解决了这个问题，所以你不需要更改你的查询。您可以很容易地在AWS上使用较新的Presto版本，只是不能无服务器。