ARROW-10817: [Rust] [DataFusion] Implement TypedString and DATE coercion

[seddonm1]

This PR adds support for what the sqlparser crate calls TypedString which is basically syntactic sugar for an inline-cast. As this was an effort to get the TPC-H queries behaving correctly I then went a step further and added support for Date (temporal) coercion. I can split this PR if needed.

where
l_shipdate <=date'1998-09-02'

is equivalent to

where
l_shipdate <= CAST('1998-09-02'ASDATE)

FYI I am planning to tackle INTERVAL next.

[github-actions]

https://issues.apache.org/jira/browse/ARROW-10817

[codecov-io]

Codecov Report

Merging #8892 (536bb1b) into master (3deae8d) will increase coverage by 24.05%.
The diff coverage is 77.41%.

@@ Coverage Diff @@## master #8892 +/- ##
===========================================
+ Coverage 52.98% 77.04% +24.05% 
===========================================
Files 172 173 +1 Lines 30750 40172 +9422 ===========================================
+ Hits 16294 30950 +14656 + Misses 14456 9222 -5234 

Impacted Files	Coverage Δ
rust/datafusion/src/physical_plan/expressions.rs	0.00% <ø> (ø)
rust/datafusion/src/sql/planner.rs	0.00% <0.00%> (ø)
rust/arrow/src/compute/kernels/cast.rs	96.33% <96.00%> (+0.12%)	⬆️
...ntegration-testing/src/bin/arrow-file-to-stream.rs
...ion-testing/src/bin/arrow-json-integration-test.rs
...ntegration-testing/src/bin/arrow-stream-to-file.rs
rust/parquet/src/util/hash_util.rs	95.77% <0.00%> (ø)
rust/parquet/src/util/bit_packing.rs	99.96% <0.00%> (ø)
rust/parquet/src/file/footer.rs	96.22% <0.00%> (ø)
rust/parquet/src/util/test_common/file_util.rs	77.77% <0.00%> (ø)
... and 49 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b0b9269...536bb1b. Read the comment docs.

[seddonm1]

@andygrove could you please have a look?

[andygrove]

Thanks @seddonm1 this looks great 🚀

[andygrove]

I should note that these changes make the test more realistic and will likely reduce performance so we will need to bear this in mind when comparing benchmark results to previous results.

[seddonm1]

Thanks Andy. I will resolve the merge conflict.

[seddonm1]

Rebased so should be good to merge.

[alamb]

I agree -- looks great @seddonm1 !

[Dandandan]

Shouldn't this have between that was also added recently? @seddonm1

[seddonm1]

yes, sorry i will fix this.

[seddonm1]

Actually, no. The raw query as per TPC-H does not use between for that clause:

where l_shipdate >=date'[DATE]'and l_shipdate <date'[DATE]'+ interval '1' year
and l_discount between [DISCOUNT] -0.01and [DISCOUNT] +0.01

Which is different as BETWEEN is inclusive (>= AND <=)

[Dandandan]

I see a between on the last line?

[seddonm1]

Oh yes, sorry I thought you meant add it to the l_shipdate component. Yes, i will fix that.

[Dandandan]

@andygrove I am actually expecting that comparison on date (in ms since epoch / int64) should be faster than on strings (if no weird implementation)?

@seddonm1 unfortunately I am getting an error on master, as the CSV reader doesn't support dates yet.

Running benchmarks with the following options: BenchmarkOpt { query: 10, debug: false, iterations: 10, concurrency: 10, batch_size: 20000, path: "/home/danielheres/Code/gdd/arrow/rust/benchmarks/tpch-dbgen", file_format: "tbl", mem_table: true }
Loading table 'part' into memory
Loaded table 'part' into memory in 157 ms
Loading table 'supplier' into memory
Loaded table 'supplier' into memory in 12 ms
Loading table 'partsupp' into memory
Loaded table 'partsupp' into memory in 553 ms
Loading table 'customer' into memory
Loaded table 'customer' into memory in 139 ms
Loading table 'orders' into memory
Error: ArrowError(ParseError("Unsupported data type Date32(Day)"))

[andygrove]

@Dandandan I was thinking about the overhead of converting the strings to dates, but you're right, if the data is stored natively in date format in Parquet then it should be faster. It would be slower than before against CSV though, probably.

[Dandandan]

@andygrove makes sense

[Dandandan]

@andygrove checked it, in #8913 , indeed parsing is a bit slower, queries are faster

[alamb]

@andygrove checked it, in #8913 , indeed parsing is a bit slower, queries are faster

That is the right tradeoff in my opinion

[alamb]

Sorry I reopened this by accident.