Skip to content

branch-4.1: [improvement](function) Add dictionary fast path for day and week arithmetic #67184 - #67233

Open
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-67184-branch-4.1
Open

branch-4.1: [improvement](function) Add dictionary fast path for day and week arithmetic #67184#67233
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-67184-branch-4.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #67184

…thmetic (#67184)

`days_add`, `days_sub`, `weeks_add`, and `weeks_sub` on DATEV2 and
DATETIMEV2
currently use the generic `DateV2Value::date_add_interval` path for
every row.
That path constructs a `TimeInterval`, converts the date through
second-level
arithmetic, and rebuilds date and time fields even though day and week
intervals
only move the date part.

This PR adds an inline `DateV2Value::date_add_days` fast path. Dates in
the
existing 1900-2039 day-offset dictionary use direct day-number and
reverse-date
lookups; inputs or results outside that dictionary retain the generic
implementation. DATETIMEV2 keeps its time fields unchanged, and result
range
checks preserve the existing out-of-range behavior.

An author microbenchmark measured approximately 8.8 ns to 2.6 ns per row
for
clustered dates and 8.8 ns to 3.5 ns for dates spread across 1950-2030.

Differential coverage compares the new helper with the generic
implementation
across the supported date domain. Focused function tests cover leap
years,
boundaries, large deltas, DATEV2, DATETIMEV2, add/subtract paths, and
out-of-range results.

### Release note

None

### Check List (For Author)

- Test
    - [x] Unit Test
    - [ ] Regression test
    - [ ] Manual test
    - [ ] No need to test or manual test
- Behavior changed:
    - [x] No
    - [ ] Yes
- Does this need documentation?
    - [x] No
    - [ ] Yes

Validation:

- `./run-be-ut.sh --run
--filter='VDateTimeValueTest.date_add_days_matches_date_add_interval:VTimestampFunctionsTest.days_add_v2_test:VTimestampFunctionsTest.days_add_v2_boundary_test:VTimestampFunctionsTest.days_sub_v2_test:VTimestampFunctionsTest.weeks_add_v2_test:VTimestampFunctionsTest.weeks_add_v2_boundary_test:VTimestampFunctionsTest.weeks_sub_v2_test'
-j16` — 7 tests passed under ASAN_UT.
- `build-support/check-build-hygiene.sh` — passed.
- `build-support/clang-format.sh`, `build-support/check-format.sh`, and
`git diff --check origin/master...HEAD` — passed.
- `build-support/run-clang-tidy.sh --base origin/master --build-dir
be/ut_build_ASAN` — no diagnostics on changed ranges after the targeted
suppression for GTest macro expansion; the overall command remains
non-zero because of pre-existing diagnostics outside the diff and
toolchain header-resolution errors such as missing `stddef.h`.
@github-actions
github-actions Bot requested a review from yiguolei as a code owner August 27, 2026 14:13
@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?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

BE UT Coverage Report

Increment line coverage 90.00% (36/40) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 59.39% (25634/43160)
Line Coverage 43.88% (262022/597109)
Region Coverage 39.83% (207656/521297)
Branch Coverage 41.31% (95742/231759)

@hello-stephen

Copy link
Copy Markdown
Contributor

BE Regression && UT Coverage Report

Increment line coverage 100.00% (36/36) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 74.20% (31202/42053)
Line Coverage 58.36% (345855/592616)
Region Coverage 55.07% (287802/522576)
Branch Coverage 56.00% (129646/231493)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants