Fix DataFusion EventDate handling: cast UInt16 to DATE

[KARTIK64-rgb]

Summary

ClickBench encodes EventDate as a UInt16 representing days since
1970-01-01. The DataFusion runner was treating it as a raw integer,
causing ClickBench queries 36–42 to return 0 rows due to broken date
range predicates.

Changes

• Updated the DataFusion runner scripts under datafusion/ to cast
  EventDate from UInt16 to a proper SQL DATE:

  CAST(CAST("EventDate" AS INTEGER) AS DATE)

  Correctness fix — no meaningful performance impact.

• Without this change, queries Q37-Q43 that filter on EventDate using date literals (e.g., >= '2013-07-01') return incorrect results (0 rows) because EventDate is stored as INT32 in the parquet file and DataFusion compares it against string literals. The new view casts EventDate to a proper DATE type

References

• Fixes Update ClickBench runner scripts to treat EventDate as a Date (not Int16) apache/datafusion#19995
• Mirrors the fix from Fix ClickBench EventDate handling by casting UInt16 days-since-epoch to DATE via hits view apache/datafusion#19881

[CLAassistant]

All committers have signed the CLA.

[alamb]

I think we need to apply the same thing to the partitioned version in https://github.com/ClickHouse/ClickBench/tree/main/datafusion-partitioned as well

[KARTIK64-rgb]

-Sure sir
-I will update the datafusion-partitioned/create.sql.
thanks for guiding.

[alamb]

Thanks @KARTIK64-rgb - this looks good

[alamb]

This is also related to the discussion here, several years ago

• Parquet file doesn't mark date and timestamp columns #7

[rschu1ze]

I checked out this PR, then ran cd datafusion and ./benchmark and it printed this (after successfully compiling datafusion):

[...]

2026-03-01 11:06:31 (95.4 MB/s) - ‘hits.parquet’ saved [14779976446/14779976446]

Run benchmarks

[0.015, 0.003, 0.003],
[0.015, 0.003, 0.003],
[0.014, 0.003, 0.003],
[0.014, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.011, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.015, 0.003, 0.003],
[0.011, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.013, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.013, 0.003, 0.003],
[0.011, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.013, 0.003, 0.003],
[0.014, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.012, 0.003, 0.003],
[0.012, 0.003, 0.004],
[0.013, 0.004, 0.003],
[0.012, 0.003, 0.003],
[0.013, 0.003, 0.003],
[0.013, 0.003, 0.003],
[0.011, 0.003, 0.003],
[0.012, 0.003, ^C

The printed values are obviously unrealistically low.

To double-check, I ran datafusion-cli manually:

arrow-datafusion/target/release/./datafusion-cli -f create.sql /tmp/query.sql

(query.sql contained one of the ClickBench queries). This ran for > 30 seconds and printed a reasonable output. It looks like something is wrong with the way how run.sh parses datafusion-cli's output. Can't tell if the problem was introduced with this PR or if it existed already before. Anyways, would you like to check / fix this? Thanks!

[KARTIK64-rgb]

thanks for the update i will check out what's the issue .