TPC-H Q16 fails during deserialization

[NGA-TRAN]

Describe the bug

Datadog is working on building a distributed version of DataFusion, which requires query serialization and deserialization. While testing with TPC-H queries, we found that Q16 fails during deserialization—potentially due to an issue in the serialization step. I've minimized the query to a smaller form that still reproduces the problem.

SELECT p_size FROM part WHERE p_size IN (14, 6, 5, 31)

To Reproduce

See this PR for the reproducer

Expected behavior

The deserialization of the query should work

Additional context

• You can only reproduce this on actual TPC-H data. See the comments in the repro for the details
• You won't hit the bug if the number of items in the list is 3 or fewer. E.g. `(14, 6, 5)
• The same bug still happens if you replace SELECT p_size with SELECT p_brand but the mismatch data type in the erorr message is now different. It looks to me the data type of the list (14, 6, 5, 31) was wrongly read from some schema during serialization/deserialization and that schema depends on the query and the parquet file

[ding-young]

After investigation based on the reproducer, it seems like the index of the column p_size is wrong since it read from different schema.

Although the data type of p_size of Int32, it returns Int64 here

datafusion/datafusion/physical-expr/src/expressions/in_list.rs

Line 446 in 3118b81

let expr_data_type = expr.data_type(schema)?;

It's because the index of column p_size is based on the schema that contains only p_size, while we use the whole schema for part table on deserialization.

Schema { [Field { name: "p_size", data_type: Int32 ... }
Schema { [Field { name: "p_partkey", data_type: Int64 },.. Field { name: "p_size", data_type: Int32 ... }}

Since index 0 for the latter is p_partkey (Int64), the error msg said data type mismatches.

[XiangpengHao]

Taking a look as LiquidCache also run into this

[XiangpengHao]

Filled a fix, but need to dig deeper to understand why it doesn't trigger the bug in df47