BiteTheDDDDt commented on code in PR #65903:
URL: https://github.com/apache/doris/pull/65903#discussion_r3630277076
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/Cast.java:
##########
@@ -273,10 +281,38 @@ public Expression withConstantArgs(Expression literal) {
@Override
public boolean isMonotonic(Literal lower, Literal upper) {
- // Both upward and downward casting of date types satisfy monotonicity.
- if (child().getDataType() instanceof DateLikeType && targetType
instanceof DateLikeType) {
+ DataType childType = child().getDataType();
+ if (!(childType instanceof DateLikeType && targetType instanceof
DateLikeType)) {
+ return false;
+ }
+
+ if (childType instanceof TimeStampTzType && targetType instanceof
DateTimeV2Type) {
+ return isTimeStampTzToDateTimeV2Monotonic(lower, upper);
+ }
+ return true;
+ }
+
+ private boolean isTimeStampTzToDateTimeV2Monotonic(Literal lower, Literal
upper) {
+ ZoneId timeZone;
+ try {
+ timeZone = DateUtils.getTimeZone();
Review Comment:
Thanks. I'm leaving this unchanged in this focused fix. The implementation
follows the existing FE monotonicity certification used by `ConvertTz` and
`FromUnixtime`, which also uses `DateUtils.getTimeZone()` and
`ZoneRules`/`hasFallbackTransitionInInstantRange` (introduced in #63853).
Resolving FE JVM tzdb versus BE cctz version skew would require a cross-cutting
timezone-data/version contract or transporting BE transition data; disabling
every named-zone optimization only here would be inconsistent and substantially
broader. I'll leave this thread open for maintainer judgment.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/Cast.java:
##########
@@ -273,10 +281,38 @@ public Expression withConstantArgs(Expression literal) {
@Override
public boolean isMonotonic(Literal lower, Literal upper) {
- // Both upward and downward casting of date types satisfy monotonicity.
- if (child().getDataType() instanceof DateLikeType && targetType
instanceof DateLikeType) {
+ DataType childType = child().getDataType();
+ if (!(childType instanceof DateLikeType && targetType instanceof
DateLikeType)) {
+ return false;
+ }
+
+ if (childType instanceof TimeStampTzType && targetType instanceof
DateTimeV2Type) {
+ return isTimeStampTzToDateTimeV2Monotonic(lower, upper);
+ }
+ return true;
+ }
+
+ private boolean isTimeStampTzToDateTimeV2Monotonic(Literal lower, Literal
upper) {
+ ZoneId timeZone;
+ try {
+ timeZone = DateUtils.getTimeZone();
+ } catch (DateTimeException e) {
+ return false;
+ }
+ if (timeZone.getRules().isFixedOffset()) {
return true;
}
- return false;
+ if (!(lower instanceof TimestampTzLiteral) || !(upper instanceof
TimestampTzLiteral)) {
+ return false;
+ }
+
+ // TimestampTzLiteral stores UTC civil fields. The cast renders those
instants in the
+ // session timezone, which moves backward at a fall-back transition.
+ Instant lowerInstant = ((TimestampTzLiteral)
lower).toJavaDateType().toInstant(ZoneOffset.UTC);
+ Instant upperInstant = ((TimestampTzLiteral)
upper).toJavaDateType().toInstant(ZoneOffset.UTC);
+ if (upperInstant.isBefore(lowerInstant)) {
+ return false;
+ }
+ return !DateUtils.hasFallbackTransitionInInstantRange(timeZone,
lowerInstant, upperInstant);
Review Comment:
Addressed in caecc0da0a1. For non-fixed zones, TIMESTAMPTZ -> DATETIMEV2 now
returns non-monotonic whenever the target scale is lower than the source scale,
so rounding cannot move an unchecked bound across a fall-back transition.
Fixed-offset zones retain monotonicity because scale rounding remains
non-decreasing and no offset transition exists. I also added the reported
`05:59:59.900000Z` boundary and a fixed-offset control to
`CastMonotonicityTest`.
##########
regression-test/suites/datatype_p0/timestamptz/test_timestamptz_rf_partition_prune_dst.groovy:
##########
@@ -0,0 +1,89 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied. See the License for the
+// specific language governing permissions and limitations
+// under the License.
+
+suite("test_timestamptz_rf_partition_prune_dst") {
+ sql "SET time_zone='America/New_York'"
+ sql "SET enable_nereids_planner=true"
+ sql "SET enable_fallback_to_original_planner=false"
+ sql "SET enable_runtime_filter_prune=false"
+ sql "SET runtime_filter_wait_infinitely=true"
+ sql "SET runtime_filter_mode='GLOBAL'"
+ sql "SET runtime_filter_type='IN_OR_BLOOM_FILTER'"
Review Comment:
Addressed in caecc0da0a1. The regression now sets
`runtime_filter_max_in_num=1024`, so `IN_OR_BLOOM_FILTER` stays on the IN path
and exercises RANGE runtime-filter partition pruning deterministically. The
expected result is unchanged.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
