Push down predicate involving timestamp_tz in Delta Lake

[kasiafi]

Description

Certain expressions involving TIMESTAMP WITH TIME ZONE can be optimized in Delta Lake connector based on the fact that columns of type TIMESTAMP WITH TIME ZONE are represented using the UTC time zone:

• date_trunc('...', timeztamp_tz_column) <comparison> constant
• CAST(timestamp_tz_column AS DATE) <comparison> constant
• year(timestamp_tz_column) <comparison> constant

The optimization is based on similar optimization in the Iceberg connector.

Fixes #18664

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
(x) Release notes are required, with the following suggested text:

# Delta Lake connector
* Pushdown filters involving columns of type TIMESTAMP WITH TIME ZONE. ({issue}`18664`)

[findinpath]

Suggested change

	* {@link TimestampWithTimeZoneType}. Such unwrap would not be monotonic. If we know
	* {@link TimestampWithTimeZoneType}. Such unwrap would not be monotonic. We know

[findinpath]

same for the other occurences

[kasiafi]

If the "if" was removed, it would suggest that this is always true that the time zone is UTC. It can be only guaranteed per connector, and the optimization only applies to those connectors.

[findinpath]

Reduce code redundancy with the method testExtractTimestampTzMicrosDateComparison

[kasiafi]

When writing this, I experimented with extracting common code for similar test methods. I eventually settled for more repetition, as it improves readability a lot.

[findinpath]

optional: This assertion can be added as well.

        assertThat(query("SELECT * FROM " + tableName + " WHERE date_trunc('hour', part) >= TIMESTAMP '2005-09-10 00:00:00.001 +07:00'"))
                .isFullyPushedDown();

[kasiafi]

Added a similar test case, thanks!

[mosabua]

@kasiafi and others... do we need to add a pushdown section to the performance section in the Delta Lake connector docs .. some here https://trino.io/docs/current/connector/delta-lake.html#performance

Similar to how we do it for JDBC connectors like https://trino.io/docs/current/connector/postgresql.html#pushdown

[findinpath]

do we need to add a pushdown section to the performance section in the Delta Lake connector docs ?

I tend to say no - the improvemenst covered by this PR (which btw exist for Iceberg connector as well) are goodies that should just be there - they are "obvious" from user perspective.

While we were working on these topics on Iceberg, we've published a blog post about them https://trino.io/blog/2023/04/11/date-predicates.html

[findepi]

goodies that should just be there - they are "obvious" from user perspective.

💯 user docs is not the place to brag about various optimization techniques we are using.
for example, we don't document all the optimizer rules that we ship

[mosabua]

Okay .. thanks @findepi and @findinpath