Skip to content

branch-4.0:[fix](partition_prune) Avoid incorrect convert_tz partition pruning across DST transitions #63853#64827

Merged
morningman merged 1 commit into
apache:branch-4.0from
feiniaofeiafei:pick-convert-tz
Jun 25, 2026
Merged

branch-4.0:[fix](partition_prune) Avoid incorrect convert_tz partition pruning across DST transitions #63853#64827
morningman merged 1 commit into
apache:branch-4.0from
feiniaofeiafei:pick-convert-tz

Conversation

@feiniaofeiafei

Copy link
Copy Markdown
Contributor

picked from #63853

…cross DST transitions (apache#63853)

### What problem does this PR solve?

Related PR: apache#40047 apache#64029

Problem Summary:

Nereids currently treats `convert_tz()` as monotonic whenever both
timezone arguments are constant. That assumption is not always correct.

When a partition predicate contains `convert_tz(partition_col, from_tz,
to_tz)`, partition pruning folds the partition range endpoints and
infers a value range for the function. This is only valid if
`convert_tz()` is monotonic on the current partition range.

Across DST transitions, `convert_tz()` is not monotonic:
- during fall-back, different input timestamps can map to the same local
time
- during spring-forward, a local-time gap can break the endpoint-based
range inference

As a result, FE may prune partitions that still contain matching rows.
The reported case is `convert_tz(ts, 'UTC', 'Europe/Paris')` around the
Europe/Paris DST fall-back boundary, where a valid partition is
incorrectly removed.

This PR fixes the issue by tightening the monotonicity check for
`convert_tz()`:
- keep the optimization for fixed-offset timezones
- disable the monotonic shortcut when the source local-time range
touches a DST transition window
- disable the monotonic shortcut when the corresponding target instant
range touches a DST transition

This keeps normal partition pruning behavior for safe cases while
avoiding wrong pruning around DST boundaries.
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@feiniaofeiafei

Copy link
Copy Markdown
Contributor Author

run buildall

@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Jun 25, 2026
@github-actions

Copy link
Copy Markdown
Contributor

PR approved by at least one committer and no changes requested.

@github-actions

Copy link
Copy Markdown
Contributor

PR approved by anyone and no changes requested.

@morningman
morningman merged commit b66f1f5 into apache:branch-4.0 Jun 25, 2026
28 of 32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants