Skip to content

[SPARK-57169][SQL] Simplify NextDay codegen under ANSI mode#56219

Closed
gengliangwang wants to merge 1 commit into
apache:masterfrom
gengliangwang:spark-next-day-codegen
Closed

[SPARK-57169][SQL] Simplify NextDay codegen under ANSI mode#56219
gengliangwang wants to merge 1 commit into
apache:masterfrom
gengliangwang:spark-next-day-codegen

Conversation

@gengliangwang
Copy link
Copy Markdown
Member

What changes were proposed in this pull request?

Add DateTimeExpressionUtils.getNextDateExact(int startDate, UTF8String dayOfWeek) and route NextDay's ANSI (failOnError = true) eval and codegen paths through it.

In ANSI mode the previous codegen emitted try { ... } catch (SparkIllegalArgumentException e) { throw e; } -- a no-op catch that simply rethrew the same exception. The ANSI branch now emits a single getNextDateExact(...) call with no try/catch (the helper lets the SparkIllegalArgumentException from DateTimeUtils.getDayOfWeekFromString propagate, which is exactly the ANSI behavior). The non-ANSI branch keeps the inline try/catch -> isNull form (matching the already-merged MakeDate / MakeInterval cleanups). The dayOfWeek.foldable constant-folding fast path is unchanged. The eval path delegates to the same helper for consistency.

Why are the changes needed?

Part of SPARK-56908 (umbrella). Dropping the dead try/catch wrapper (and the two chained DateTimeUtils calls) in the ANSI path shrinks the generated Java for next_day, helping with the JVM 64KB method / constant-pool limits, Janino compile time, and JIT work.

Does this PR introduce any user-facing change?

No. The compiled behavior is identical; only the emitted Java source text changes.

How was this patch tested?

build/sbt "catalyst/testOnly *DateExpressionsSuite"

75/75 pass, including next_day (exercised both with and without whole-stage codegen).

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 4.8)

@gengliangwang gengliangwang requested a review from LuciferYang May 31, 2026 02:31
@gengliangwang gengliangwang force-pushed the spark-next-day-codegen branch from e220acc to ff100ff Compare June 1, 2026 02:16
Add `DateTimeExpressionUtils.getNextDateExact(int startDate, UTF8String
dayOfWeek)` and route `NextDay`'s ANSI (`failOnError = true`) eval and codegen
paths through it.

In ANSI mode the previous codegen emitted
`try { ... } catch (SparkIllegalArgumentException e) { throw e; }` -- a no-op
catch that simply rethrew the same exception. The ANSI branch now emits a single
`getNextDateExact(...)` call with no try/catch (the helper lets the
`SparkIllegalArgumentException` from `getDayOfWeekFromString` propagate, which is
exactly the ANSI behavior). The non-ANSI branch keeps the inline
`try/catch -> isNull`. The `dayOfWeek.foldable` constant-folding fast path is
unchanged.

Part of SPARK-56908 (umbrella). Dropping the dead try/catch wrapper (and the two
chained `DateTimeUtils` calls) in the ANSI path shrinks the generated Java for
`next_day`.

No. The compiled behavior is identical; only the emitted Java source text changes.

```
build/sbt "catalyst/testOnly *DateExpressionsSuite"
```

75/75 pass, including `next_day` (exercised both with and without whole-stage
codegen).

Generated-by: Claude Code (Opus 4.8)

Co-authored-by: Isaac
@gengliangwang gengliangwang force-pushed the spark-next-day-codegen branch from ff100ff to 5e9e9ed Compare June 1, 2026 03:33
@gengliangwang
Copy link
Copy Markdown
Member Author

@LuciferYang thanks for the review. Merging to master/4.x

gengliangwang added a commit that referenced this pull request Jun 1, 2026
### What changes were proposed in this pull request?

Add `DateTimeExpressionUtils.getNextDateExact(int startDate, UTF8String dayOfWeek)` and route `NextDay`'s ANSI (`failOnError = true`) eval and codegen paths through it.

In ANSI mode the previous codegen emitted `try { ... } catch (SparkIllegalArgumentException e) { throw e; }` -- a no-op catch that simply rethrew the same exception. The ANSI branch now emits a single `getNextDateExact(...)` call with no try/catch (the helper lets the `SparkIllegalArgumentException` from `DateTimeUtils.getDayOfWeekFromString` propagate, which is exactly the ANSI behavior). The non-ANSI branch keeps the inline `try/catch -> isNull` form (matching the already-merged `MakeDate` / `MakeInterval` cleanups). The `dayOfWeek.foldable` constant-folding fast path is unchanged. The eval path delegates to the same helper for consistency.

### Why are the changes needed?

Part of SPARK-56908 (umbrella). Dropping the dead try/catch wrapper (and the two chained `DateTimeUtils` calls) in the ANSI path shrinks the generated Java for `next_day`, helping with the JVM 64KB method / constant-pool limits, Janino compile time, and JIT work.

### Does this PR introduce _any_ user-facing change?

No. The compiled behavior is identical; only the emitted Java source text changes.

### How was this patch tested?

```
build/sbt "catalyst/testOnly *DateExpressionsSuite"
```

75/75 pass, including `next_day` (exercised both with and without whole-stage codegen).

### Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 4.8)

Closes #56219 from gengliangwang/spark-next-day-codegen.

Authored-by: Gengliang Wang <gengliang@apache.org>
Signed-off-by: Gengliang Wang <gengliang@apache.org>
(cherry picked from commit c19056a)
Signed-off-by: Gengliang Wang <gengliang@apache.org>
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