Skip to content

[improvement](fe) Support hour-offset date_add/date_sub in MTMV partition refresh#62535

Closed
hakanuzum wants to merge 0 commit intoapache:masterfrom
hakanuzum:feat/mtmv-date-add-interval-partition-v2
Closed

[improvement](fe) Support hour-offset date_add/date_sub in MTMV partition refresh#62535
hakanuzum wants to merge 0 commit intoapache:masterfrom
hakanuzum:feat/mtmv-date-add-interval-partition-v2

Conversation

@hakanuzum
Copy link
Copy Markdown

What problem does this PR solve?

Issue Number: close #62395

Related PR: None

Problem Summary:

MTMV (Materialized View) partition rollup and incremental refresh logic previously only handled partition expressions of the form:

date_trunc(partition_col, 'unit')

It could not recognize or process expressions where a hour-level offset is applied to the partition column before truncation, such as:

date_trunc(date_add(partition_col, INTERVAL N HOUR), 'unit')
date_trunc(date_sub(partition_col, INTERVAL N HOUR), 'unit')

This pattern is widely used in production pipelines where raw data is stored in UTC but the MV must partition by local business-day boundaries (e.g., UTC+3 → date_add(event_time, INTERVAL 3 HOUR)). Without this support:

  • Partition lineage between the base table and MTMV could not be established.
  • Incremental refresh predicate generation failed silently, causing full refresh fallback or incorrect partition mapping.
  • PartitionIncrementMaintainer rejected these expressions as unsupported, blocking partition-aware query rewrite.

The root causes were:

  1. MTMVPartitionExprFactory only returned MTMVPartitionExprDateTrunc for any date_trunc(...) call, with no branch for the inner date_add/date_sub case.
  2. PartitionIncrementChecker.SUPPORT_EXPRESSION_TYPES did not include HoursAdd, HoursSub, or Cast, so any MV defined with these expressions was rejected during increment check.
  3. There was no rollup service implementation that could compute partition identity and generate range bounds when an hour offset is involved.

What is changed and how does it work?

New class — MTMVPartitionExprDateTruncDateAddSub:

Implements MTMVPartitionExprService for expressions of the form date_trunc(date_add/date_sub(col,INTERVAL N HOUR), 'unit').

Key responsibilities:

  • Parses the date_trunc outer function and extracts the truncation unit.
  • Parses the inner TimestampArithmeticExpr (date_add/date_sub) and converts the hour offset to a signed long (date_sub → negative offset).
  • getRollUpIdentity(): applies the offset to each partition value and truncates, returning a stable identity string for lineage mapping.
  • generateRollUpPartitionKeyDesc(): computes [lower, upper) range bounds in the MV partition space, applying the offset before truncation and incrementing by the appropriate time unit (day, week, month, year, quarter, hour).
  • analyze(): validates that the truncation unit is supported and that the base table uses RANGE partitioning with a DATE/DATETIME column.
  • toSql(): regenerates the canonical SQL expression for the partition expression.

MTMVPartitionExprFactory — routing logic extended:

Added a guard inside the date_trunc branch: if the first argument is a TimestampArithmeticExpr (i.e., date_add/date_sub), the factory now returns MTMVPartitionExprDateTruncDateAddSub instead of the plain MTMVPartitionExprDateTrunc.

if (paramsExprs.size() == 2 && paramsExprs.get(0) instanceof TimestampArithmeticExpr) {
    return new MTMVPartitionExprDateTruncDateAddSub(functionCallExpr);
}
return new MTMVPartitionExprDateTrunc(functionCallExpr);

PartitionIncrementMaintainer.PartitionIncrementChecker:

Extended SUPPORT_EXPRESSION_TYPES to include Cast, HoursAdd, and HoursSub,
allowing the increment checker to traverse and validate MV partition expressions
that contain these node types:

ImmutableSet.of(Cast.class, DateTrunc.class, HoursAdd.class, HoursSub.class,
    SlotReference.class, Literal.class)

UpdateMvByPartitionCommand and MTMVPartitionDefinition:

Minor adjustments to pass the hour-offset partition expr through the incremental
refresh predicate builder without being rejected.


Example

Base table partitioned by hour-level UTC timestamp:

CREATE TABLE orders (
    order_id BIGINT,
    event_time DATETIME NOT NULL
) PARTITION BY RANGE(event_time) ( ... )
DISTRIBUTED BY HASH(order_id);

MTMV partitioned by local business day (UTC+3):

CREATE MATERIALIZED VIEW orders_by_local_day
BUILD IMMEDIATE REFRESH ON MANUAL
PARTITION BY (date_trunc(date_add(event_time, INTERVAL 3 HOUR), 'day'))
DISTRIBUTED BY HASH(order_id)
AS SELECT
    date_trunc(date_add(event_time, INTERVAL 3 HOUR), 'day') AS local_day,
    count(*) AS cnt
FROM orders
GROUP BY local_day;

Before this PR: Creating this MV would fail or fall back to full refresh because the partition expression date_trunc(date_add(...), 'day') was not recognized.

After this PR: Partition lineage is correctly established. Incremental refresh only recomputes partitions whose source data changed, and the predicate pushed down to the base table correctly accounts for the 3-hour offset window.


Behavior change

Scenario Before After
date_trunc(col, 'day') ✅ Supported ✅ No change
date_trunc(date_add(col, INTERVAL N HOUR), 'day/week/month/year') ❌ Lineage broken, full refresh ✅ Incremental refresh works
date_trunc(date_sub(col, INTERVAL N HOUR), 'day/week/month/year') ❌ Not recognized ✅ Supported
PartitionIncrementChecker with HoursAdd/HoursSub nodes ❌ Rejected ✅ Passes validation

Backward compatible. No change to existing date_trunc(col, unit) behavior.


Release note

Support MTMV partition rollup and incremental refresh for date_trunc(date_add/date_sub(partition_col, INTERVAL N HOUR), 'unit'). This enables local-timezone day partitioning on UTC-stored tables via Async Materialized Views.


Check List (For Author)

  • Test

    • FE Unit Test:
      ./run-fe-ut.sh --run org.apache.doris.mtmv.MTMVRelatedPartitionDescRollUpGeneratorTest
    • Regression test:
      ./run-regression-test.sh --run -d mtmv_p0 -s test_rollup_partition_mtmv_date_add
    • Manual test: Validated with FE build against a local single-node cluster.
      MVN_OPT='-Dmaven.build.cache.enabled=false' ./build.sh --fe --clean -j$(nproc)
  • Behavior changed: Yes
    date_trunc(date_add/date_sub(..., INTERVAL N HOUR), unit) partition expressions are now supported for MTMV partition lineage and incremental refresh.

  • Does this need documentation: Yes
    The MTMV partition expression documentation should be updated to list date_trunc(date_add/date_sub(col, INTERVAL N HOUR), unit) as a supported form.

@Thearas
Copy link
Copy Markdown
Contributor

Thearas commented Apr 15, 2026

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?

@hakanuzum
Copy link
Copy Markdown
Author

/review

@hakanuzum
Copy link
Copy Markdown
Author

run buildall

@hakanuzum
Copy link
Copy Markdown
Author

Workflows show 'awaiting approval' (fork PR). Could a maintainer approve the workflows and review the PR when possible? I already posted '/review' and 'run buildall' to trigger the required checks.

@hakanuzum
Copy link
Copy Markdown
Author

Merged latest upstream/master into this PR branch (no conflicts). Triggering CI on the new head sha: run buildall

@hakanuzum
Copy link
Copy Markdown
Author

/review

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Findings

  1. fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/info/MTMVPartitionDefinition.java
    The new HoursAdd / HoursSub conversion only fixes the later legacy-expression conversion step. The create/analyze path still derives partitionColName only when the first date_trunc argument is an UnboundSlot, so PARTITION BY (date_trunc(date_add(k2, INTERVAL 3 HOUR), 'day')) still fails before it reaches the new helper.
  2. fe/fe-core/src/main/java/org/apache/doris/mtmv/MTMVPartitionExprDateTruncDateAddSub.java
    toSql() rebuilds the partition clause from mvPartitionInfo.getPartitionCol(), which is the output alias for alias-based definitions. SHOW CREATE MATERIALIZED VIEW therefore emits a different, non-round-trippable partition clause for the new expression shape.

Critical Checkpoints

  • Goal of current task: Partially met. Alias-based rollup / refresh / union-compensation paths are covered, but the direct partition-clause syntax described in the PR is still rejected, and metadata round-tripping for the new syntax is broken.
  • Modification size/focus: Reasonably focused on FE MTMV / Nereids paths.
  • Concurrency: No new concurrency or lock-order risk observed.
  • Lifecycle/static initialization: No special lifecycle concerns found.
  • Configuration items: None added.
  • Compatibility / incompatible changes: User-visible SHOW CREATE MATERIALIZED VIEW output is regressed for the new expression shape.
  • Parallel code paths: Refresh and union-compensation were updated, but create/analyze and show-create paths are inconsistent with those execution paths.
  • Special conditional checks: Offset parsing and HOUR-only checks are reasonable.
  • Test coverage: Added FE unit/regression tests cover alias-based rollup / refresh / union rewrite, but they do not cover the direct PARTITION BY (date_trunc(date_add/date_sub(...), ...)) syntax or a SHOW CREATE round-trip for the new expression.
  • Modified test results: The added tests look consistent for the paths they cover.
  • Observability: No new observability requirement identified.
  • Transaction / persistence: No journal/master-failover issue found in this FE-only change, but persisted metadata rendering is inconsistent with the supported DDL shape.
  • Data write / modification safety: Refresh predicate translation itself looks aligned after the offset fix; no new write-atomicity issue found.
  • FE-BE variable propagation: Not applicable.
  • Performance: No material performance regression identified.
  • Other issues: None beyond the blockers above.

Overall: request changes.

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking finding:

  1. fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/info/MTMVPartitionDefinition.java: the new hour-offset support is still incomplete. analyzeAndTransferToMTMVPartitionInfo() only extracts partitionColName when the first date_trunc argument is an UnboundSlot, so PARTITION BY (date_trunc(date_add/sub(col, INTERVAL N HOUR), 'unit')) still fails with partition column can not find from sql select column. The same direct form is also produced when stored partition metadata is reparsed by MTMVPlanUtil.analyzeQueryWithSql(), so alias-based MVs can later fail ensureMTMVQueryUsable() in the SCHEMA_CHANGE path.

Critical checkpoints:

  • Goal: The PR aims to support hour-offset date_add/date_sub MTMV partition rollup, refresh, and rewrite. The alias-based rollup/refresh/rewrite paths are implemented, but the direct PARTITION BY form described in the PR is still not accepted, so the goal is not fully met.
  • Scope: The change is localized to FE MTMV code and tests, but the unsupported entry point leaves the feature incomplete.
  • Concurrency: No new concurrency or lock-order issues found in the touched code.
  • Lifecycle: No static/lifecycle issues found, but persisted partition expressions are reparsed through MTMVPlanUtil.analyzeQueryWithSql(), and that round-trip still hits the unsupported direct form.
  • Configuration: No new config items.
  • Compatibility: No FE-BE protocol or storage-format compatibility issues identified.
  • Parallel code paths: Not all parallel paths are updated; the lineage conversion path is updated, but the top-level partition-definition analysis path is not.
  • Conditional checks: The new HOUR and range-only checks are reasonable, but they are not consistently enforced across all entry points because the earlier parser path rejects the feature first.
  • Test coverage: Added tests cover alias-based rollup, refresh predicate translation, and union compensation. They do not cover the direct PARTITION BY (date_trunc(date_add/sub(...), ...)) form or the re-analysis path that uses persisted metadata.
  • Test result changes: No .out files were modified. The new Groovy and unit-test changes look structurally fine.
  • Observability: No extra observability appears necessary for this FE expression-handling change.
  • Transaction and persistence: No edit-log format change, but persisted partition expressions are affected by the incomplete re-analysis path above.
  • Data writes and modifications: No new atomicity problems found beyond the incomplete partition-analysis path.
  • FE-BE variable passing: None.
  • Performance: No obvious performance regressions in the touched code.
  • Other issues: No additional blocking issues identified beyond the incomplete partition-definition handling.

Requesting changes until the direct partition-expression path and its metadata re-analysis round-trip are supported end to end.

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking issues found.

  1. Raw PARTITION BY (date_trunc(date_add/date_sub(...), ...)) is still unsupported because MTMVPartitionDefinition.analyzeAndTransferToMTMVPartitionInfo() only extracts a partition column when the outer date_trunc input is a bare slot. The same gap also breaks MTMVPlanUtil.ensureMTMVQueryUsable() once the stored expr is reparsed.
  2. MTMVPartitionExprDateTruncDateAddSub.analyze() admits DATE/DATEV2 partition columns, but the rollup boundary algorithm only works for continuous DATETIME ranges and fails on daily DATE partitions.
  3. MTMVPartitionExprDateTruncDateAddSub.toSql() serializes against the MV alias and reapplies the hour shift, so SHOW CREATE MATERIALIZED VIEW emits non-round-trippable DDL for the new feature.

Critical checkpoints:

  • Goal / correctness: Not fully achieved. Alias-based DATETIME cases are covered by the new tests, but the direct syntax described in the PR, DATE-partitioned sources, and SHOW CREATE / reanalysis paths are still broken.
  • Scope / focus: The code is focused, but companion analysis and serialization paths were missed.
  • Concurrency: No new concurrency-sensitive path identified.
  • Lifecycle / reanalysis: Fails. Stored partition expressions are reparsed in schema-change validation, and the new raw nested form cannot be re-analyzed.
  • Config / compatibility: No new config or FE/BE protocol/storage compatibility issue found.
  • Parallel code paths: Not all updated. Refresh and union compensation were adjusted, but creation analysis and SHOW CREATE round-trip were not.
  • Special conditions: Hour-offset support is conditionally added, but DATE columns violate the assumptions behind the range-boundary check.
  • Test coverage: Insufficient for this feature. Missing direct nested PARTITION BY syntax, DATE/DATEV2 range partitions with hour offsets, and SHOW CREATE / ensureMTMVQueryUsable() round-trip coverage.
  • Test result files: No .out files changed; no issue there.
  • Observability: No additional observability needed for this change.
  • Transaction / persistence / FE-BE variable passing: Not applicable here.
  • Data-write correctness: Predicate generation changes are on the right path, but correctness is still not guaranteed across the broken analysis and serialization paths.
  • Performance: No blocking performance issue found.

Testing in this review: not run locally.

hakanuzum added a commit to hakanuzum/doris that referenced this pull request Apr 16, 2026
### What problem does this PR solve?

Issue Number:

Related PR: apache#62535

Problem Summary: Support raw nested partition expressions like date_trunc(date_add/date_sub(col, INTERVAL N HOUR), unit) by extracting the underlying slot, preserving the original legacy expr, and avoiding incorrect SQL serialization. Disallow DATE/DATEV2 range partitions for hour-offset rollup to prevent incorrect boundary mapping.

### Release note

None

### Check List (For Author)

- Test: No need to test (CI)
- Behavior changed: Yes (partition expr support/validation)
- Does this need documentation: No
@hakanuzum
Copy link
Copy Markdown
Author

Pushed fixes for the automated review findings:

  • Preserve raw nested partition expr in MTMVPartitionDefinition and avoid overwriting with derived expr
  • Extract underlying slot name from nested hours_add/date_add
  • Disallow DATE/DATEV2 range partition columns for hour-offset rollup
  • Use stored legacy expr for toSql to keep SHOW CREATE round-trippable

Triggering CI: /review\nrun buildall

@hakanuzum
Copy link
Copy Markdown
Author

/review

@hakanuzum
Copy link
Copy Markdown
Author

run buildall

@hakanuzum
Copy link
Copy Markdown
Author

Head updated (merge commit 8cc5669). Re-triggering CI: /review\nrun buildall

hakanuzum added a commit to hakanuzum/doris that referenced this pull request Apr 16, 2026
### What problem does this PR solve?

Issue Number:

Related PR: apache#62535

Problem Summary: Legacy Expr does not expose a direct toSql() API. Use ExprToSqlVisitor to serialize stored MTMV partition expressions.

### Release note

None

### Check List (For Author)

- Test: No need to test (CI)
- Behavior changed: No
- Does this need documentation: No
@hakanuzum
Copy link
Copy Markdown
Author

/review

@hakanuzum
Copy link
Copy Markdown
Author

run buildall

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking issues remain in the MTMVPartitionDefinition analysis path.

  1. The new raw nested PARTITION BY handling stores the inner base slot as partitionCol. Downstream create/reanalysis code still expects mvPartitionInfo.getPartitionCol() to be a real MV output column, so raw forms like PARTITION BY (date_trunc(date_add(k2, INTERVAL 3 HOUR), 'day')) break unless the SELECT list also exposes k2.
  2. The new eager mtmvPartitionInfo.setExpr(...) plus the later if (mtmvPartitionInfo.getExpr() != null) continue; keeps the clause-level expression (date_trunc(day_alias, 'day')) instead of the lineage-derived base-table expression (date_trunc(date_add(k2, INTERVAL 3 HOUR), 'day')). That loses the TimestampArithmeticExpr shape required by the new refresh and union-compensation logic.

Critical checkpoints:

  • Goal / correctness: Not satisfied end to end. The PR aims to support hour-offset date_add/date_sub partition expressions for MTMV rollup, refresh, and rewrite, but the current partition-metadata handoff breaks both raw nested partition clauses and alias-based hour-offset MVs.
  • Minimality / focus: Mostly focused, but the final MTMVPartitionDefinition fix mixes show-create concerns with runtime partition metadata and introduces the regressions above.
  • Concurrency: No new concurrency or locking issues found in these FE paths.
  • Lifecycle / static init: No special lifecycle or static-initialization issues found.
  • Configs: No new config items.
  • Compatibility: No FE-BE wire/storage compatibility change, but persisted and re-analyzed MTMVPartitionInfo becomes inconsistent with downstream consumers.
  • Parallel paths: Refresh and union-compensation were updated, but the create/reanalysis path is now inconsistent with them.
  • Conditional checks: The new DATE/DATEV2 rejection is explicit and reasonable.
  • Test coverage: The added FE unit and regression tests are useful for rollup and compensation, but they do not guard the broken MTMVPartitionDefinition metadata flow.
  • Test result files: No handwritten .out issues found.
  • Observability: No new observability gaps identified.
  • Transaction / persistence / data writes: No transaction or journal issue found beyond incorrect MTMV partition metadata propagation.
  • FE-BE variable passing: Not applicable.
  • Performance: No blocking performance issue found.
  • Other: No additional blocker beyond the two issues above.

@hakanuzum
Copy link
Copy Markdown
Author

Pushed fix for the automated review findings (head updated):

  • Resolve MTMV partitionCol to a real MV output column for raw nested PARTITION BY (date_trunc(date_add/date_sub(...))).
  • Prefer lineage-derived partition expr in MTMVPartitionDefinition so hour-offset partitions keep the TimestampArithmeticExpr shape.

Local test: ./run-fe-ut.sh --run org.apache.doris.mtmv.MTMVRelatedPartitionDescRollUpGeneratorTest (OrbStack Linux) ✅

/review
run buildall

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found blocking correctness issues in the new hour-offset MTMV partition path.

Findings

  • Alias-form PARTITION BY (date_trunc(day_alias, ...)) still preserves the alias expression in MTMVPartitionInfo.expr, so the new offset-aware rollup / refresh / rewrite logic never sees the traced date_add/date_sub expression.
  • Cast is stripped while persisting the partition expression, which can change the partitioning semantics that are shown, replayed, and compared later.
  • Union compensation now applies the hour offset after the code has already resolved concrete base-table partition names, so the base-table filter can be shifted twice.

Critical Checkpoints

  • Goal: Not fully accomplished. Support was added for the new syntax, but the end-to-end metadata flow is still incorrect for alias-form and cast-wrapped expressions, and union compensation can read the wrong base range.
  • Minimality: The change set is focused, but the expression source of truth is inconsistent across create, rollup, refresh, and rewrite paths.
  • Concurrency: No new concurrency or locking issue identified in the touched FE code.
  • Lifecycle / static initialization: No special lifecycle or static-init issue found.
  • Configuration: No new configuration items were added.
  • Compatibility: Risk remains. Persisted MTMVPartitionInfo.expr can diverge from the user-defined SQL when casts are present.
  • Parallel code paths: Not fully covered. Initial partition rollup, partial refresh, and union compensation still disagree on which partition expression / offset is authoritative.
  • Special conditions: The new hour-offset and cast conditions are not preserved consistently through legacy-expression conversion.
  • Test coverage: Added tests improve baseline coverage, but they miss alias-form partition-scoped refresh / rewrite cases and cast round-trip coverage.
  • Test result changes: I reviewed the added tests, but I did not run FE UT or regression tests in this runner.
  • Observability: Existing observability looks sufficient for this change.
  • Transaction / persistence: The persisted partition expression can be incorrect when casts are elided.
  • Data write / refresh correctness: Refresh and union compensation can target the wrong source range.
  • FE-BE variable passing: Not applicable for this PR.
  • Performance: No blocking performance issue found beyond the correctness problems above.
  • Other: No additional blockers beyond these findings.

@hakanuzum
Copy link
Copy Markdown
Author

Addressed the latest automated review concerns (head updated):

  • Preserve CAST in persisted MTMV partition expr (legacy conversion now keeps CAST).
  • Avoid falling back to alias-only expr for PARTITION BY (date_trunc(day_alias, ...)) (require traced expr from SELECT).
  • Fix union compensation: don't apply hour-offset shift again when filtering by base-table partition names.

Local test (OrbStack Linux): ./run-fe-ut.sh --run org.apache.doris.mtmv.MTMVRelatedPartitionDescRollUpGeneratorTest

/review
run buildall

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed current PR head 0fb897e706e22c166c5e5902a786d946ff1121a4 after the earlier pinned snapshot 0d69a3ae90697425e01aefcf225ef101b7b6ce55 was superseded by follow-up fixes. I did not find any remaining blocking issues on the current head.

Critical checkpoint conclusions:

  • Goal / correctness: The PR goal is to support date_trunc(date_add/date_sub(partition_col, INTERVAL N HOUR), ...) for MTMV partition tracking, refresh, and rewrite. On the current head, both alias-based and raw partition-clause forms appear to work end to end, and the previously reported stale issues are addressed in the updated code.
  • Scope / minimality: The change stays focused on MTMV partition-expression analysis, partition rollup service selection, refresh predicate construction, and rewrite compensation, with targeted tests alongside the code changes.
  • Concurrency / locking: I did not find new concurrency-sensitive state, lock-order changes, or FE metadata-locking regressions in the modified paths.
  • Lifecycle / compatibility / persistence: No new config items are introduced. The current code preserves the partition expression through SHOW CREATE / reanalysis in the reviewed paths and does not appear to introduce a new incompatible storage-format change.
  • Parallel code paths: The relevant parallel paths were updated consistently: partition expr factory selection, refresh-side inverse hour offset handling, and union-rewrite compensation. The earlier double-shift concern in union rewrite is not present on the current head.
  • Special conditions / validation: Unsupported shapes are still rejected, including non-hour intervals and DATE/DATEV2 partition columns for this hour-offset feature, which is the safer behavior for the current implementation.
  • Test coverage: The PR now includes FE unit coverage for rollup generation and regression coverage for alias/raw syntax, SHOW CREATE shape, union compensation, DATETIMEV2 inputs, multiple time units, and negative cases.

Residual risk: this conclusion is based on code review only. I did not run FE unit tests or regression suites in this runner.

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two blocking correctness issues found.

Critical checkpoints

  • Goal: The PR aims to support hour-offset date_add/date_sub partitions across rollup, incremental refresh, and union compensation. The DATETIME and DATETIMEV2 paths mostly work, but the implementation is still incorrect for TIMESTAMPTZ refresh and union predicates, and the new rollup service is too coarse for fractional DATETIMEV2 partition boundaries. Current tests do not cover either case.
  • Scope: The change stays focused on MTMV partition analysis, refresh, and rewrite. Size is reasonable for the feature.
  • Concurrency: No new concurrency, lock-order, or lifecycle issues found in the modified paths.
  • Configs and compatibility: No new configuration items and no FE-BE protocol changes.
  • Parallel paths: The hour-offset logic was propagated to refresh and union-compensation, which is good, but both paths share the TIMESTAMPTZ predicate-shifting hole.
  • Conditional checks: The new expression-shape validation is clear, but the TIMESTAMPTZ allowance is broader than the downstream helpers support.
  • Test coverage: Added FE UTs and regressions cover core DATETIME and DATETIMEV2 behavior, raw partition expressions, and union compensation. Missing coverage for TIMESTAMPTZ refresh or union and for fractional DATETIMEV2 partition boundaries.
  • Test result changes: The covered new results look consistent.
  • Observability: Existing errors are sufficient for these paths.
  • Transaction, persistence, and FE-BE variable passing: Not applicable in this PR.
  • Data correctness: Blocking due to wrong predicate windows for TIMESTAMPTZ and incorrect rollup validation near sub-second boundaries.
  • Performance: No material performance concern found.
  • Other issues: No additional blocking issues were confirmed in the reviewed snapshot beyond the inline comments.

Requesting changes until these correctness gaps are fixed or the unsupported types and boundary shapes are rejected explicitly.

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking findings:

  1. CAST(...)-wrapped hour-offset partition expressions are now persisted by MTMVPartitionDefinition, but MTMVPartitionExprFactory only dispatches when the first date_trunc argument is a bare TimestampArithmeticExpr. Persisted shapes like date_trunc(cast(date_add(...)), 'day') therefore fall back to MTMVPartitionExprDateTrunc, which drops the hour offset in rollup mapping, SHOW CREATE MATERIALIZED VIEW, and ensureMTMVQueryUsable().
  2. UpdateMvByPartitionCommand.getInverseHourOffsetForBaseFilter() has the same parser gap. For the same cast-preserving persisted shape it returns Optional.empty(), so incremental refresh builds base-table predicates from unshifted MV bounds.
  3. The new service explicitly accepts TIMESTAMP_TZ partition columns, but it parses partition values through DateTimeV2Literal and serializes them back without timezone information. PartitionKey.createPartitionKey() then reinterprets those bounds in the session timezone, shifting MV partition boundaries for TIMESTAMP_TZ tables.

Critical checkpoints:

  • Goal / correctness: Partially met. Bare date_trunc(date_add/date_sub(..., INTERVAL N HOUR), unit) works, but the PR does not correctly support the cast-preserving shape it now stores, and the new TIMESTAMP_TZ path produces wrong partition bounds.
  • Change focus: Reasonably focused on MTMV FE logic, but downstream readers of the persisted expr were not updated consistently.
  • Concurrency: No new concurrency or locking issues found in these code paths.
  • Lifecycle / persistence: Problematic. Persisted MTMV partition exprs can now be stored in shapes that later FE paths misinterpret.
  • Config changes: None.
  • Compatibility / storage format: No new on-wire format, but the persisted expr semantics are interpreted inconsistently for the newly accepted forms.
  • Parallel code paths: Not all applicable paths were updated. Analysis, rollup generation, show-create, reanalysis, and refresh predicate generation do not all recognize the same expression shapes.
  • Special conditions / assertions: The new TIMESTAMP_TZ acceptance lacks the required normalization and serialization guarantees.
  • Test coverage: Insufficient for the changed behavior. The added tests cover bare date_add/date_sub, but not cast-wrapped expressions or TIMESTAMP_TZ.
  • Test result changes: The added tests look correct for the cases they cover.
  • Observability: Existing logging is sufficient; no new observability requirement identified.
  • Transaction / persistence safety: No EditLog changes, but persisted partition metadata is interpreted inconsistently.
  • Data write / atomicity: No direct write-atomicity issue found.
  • FE/BE variable passing: Not applicable.
  • Performance: No blocking performance issue found.
  • Other issues: None beyond the correctness gaps above.

Comment thread fe/fe-core/src/main/java/org/apache/doris/mtmv/MTMVPartitionExprFactory.java Outdated
@hakanuzum
Copy link
Copy Markdown
Author

/review
run buildall

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found blocking issues in the new hour-offset MTMV partition flow.

Critical checkpoints:

  • Goal of the task: Not fully achieved. The new date_trunc(date_add/date_sub(..., INTERVAL N HOUR), unit) path still fails for ordinary UTC-aligned range partitions because one source partition can span two shifted MV buckets.
  • Minimality/focus: Mostly focused, but one added regression case asserts behavior the current implementation cannot materialize.
  • Concurrency: No new concurrency, locking, or lifecycle issues found in the touched paths.
  • Config/compatibility: No new config items or FE/BE protocol changes in this PR.
  • Parallel code paths: Create-time partition generation and later partition alignment both share the same rollup mapping logic, so the boundary bug affects more than one maintenance path.
  • Tests: Coverage is not sufficient for the blocking case; the new union-compensation regression uses midnight source partitions that should fail before rewrite.
  • Build/style: AbstractMaterializedViewRule adds an unused import that should fail FE checkstyle (UnusedImports).

I could not run FE mvn validate end-to-end in this runner because the local Maven environment is missing org.apache.doris:fe-foundation:1.2-SNAPSHOT, so the review is source-based.

hakanuzum added a commit to hakanuzum/doris that referenced this pull request Apr 17, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#62535

Problem Summary: Fix remaining gaps for hour-offset MTMV partition expressions by unwrapping leading CAST nodes in date_trunc(date_add/date_sub(...)) parsing paths, improving error messages for misaligned base RANGE partition boundaries, and fixing FE checkstyle import ordering.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - orb: [INFO] Scanning for projects...
[INFO] Loading cache configuration from /Users/hakanuzum/Desktop/Work/Personal/doris/fe/.mvn/maven-build-cache-config.xml
[INFO] Using XX hash algorithm for cache
[INFO] ------------------------------------------------------------------------
[INFO] Detecting the operating system and CPU architecture
[INFO] ------------------------------------------------------------------------
[INFO] os.detected.name: osx
[INFO] os.detected.arch: aarch_64
[INFO] os.detected.bitness: 64
[INFO] os.detected.version: 15.7
[INFO] os.detected.version.major: 15
[INFO] os.detected.version.minor: 7
[INFO] os.detected.classifier: osx-aarch_64
Downloading from central: https://repo.maven.apache.org/maven2/org/antlr/maven-metadata.xml
Downloading from apache.snapshots: https://repository.apache.org/snapshots/org/antlr/maven-metadata.xml
Downloading from central: https://repo.maven.apache.org/maven2/org/commonjava/maven/plugins/maven-metadata.xml
Downloading from apache.snapshots: https://repository.apache.org/snapshots/org/commonjava/maven/plugins/maven-metadata.xml
Progress (1): 535 B
                   
Downloading from central: https://repo.maven.apache.org/maven2/org/jacoco/maven-metadata.xml
Downloaded from central: https://repo.maven.apache.org/maven2/org/antlr/maven-metadata.xml (535 B at 1.7 kB/s)
Downloading from apache.snapshots: https://repository.apache.org/snapshots/org/jacoco/maven-metadata.xml
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/rat/maven-metadata.xml
Progress (1): 1.3 kB
                    
Downloaded from central: https://repo.maven.apache.org/maven2/org/commonjava/maven/plugins/maven-metadata.xml (1.3 kB at 4.3 kB/s)
Downloading from apache.snapshots: https://repository.apache.org/snapshots/org/apache/rat/maven-metadata.xml
Progress (1): 237 B
                   
Downloaded from central: https://repo.maven.apache.org/maven2/org/jacoco/maven-metadata.xml (237 B at 4.2 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/sonarsource/scanner/maven/maven-metadata.xml
Downloading from apache.snapshots: https://repository.apache.org/snapshots/org/sonarsource/scanner/maven/maven-metadata.xml
Progress (1): 249 B
Progress (2): 249 B | 240 B
                           
Downloaded from central: https://repo.maven.apache.org/maven2/org/sonarsource/scanner/maven/maven-metadata.xml (240 B at 4.1 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml
Downloading from apache.snapshots: https://repository.apache.org/snapshots/org/apache/maven/plugins/maven-metadata.xml
Downloaded from apache.snapshots: https://repository.apache.org/snapshots/org/apache/rat/maven-metadata.xml (249 B at 1.7 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml
Progress (1): 4.6 kB
Progress (1): 9.7 kB
Progress (1): 14 kB 
                   
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml (14 kB at 251 kB/s)
Downloading from apache.snapshots: https://repository.apache.org/snapshots/org/codehaus/mojo/maven-metadata.xml
Progress (1): 558 B
                   
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/rat/maven-metadata.xml (558 B at 3.2 kB/s)
Progress (1): 7.6/8.9 kB
Progress (1): 8.2/8.9 kB
Progress (1): 8.9 kB    
Progress (2): 8.9 kB | 3.1 kB
Progress (2): 8.9 kB | 7.7 kB
Progress (2): 8.9 kB | 12 kB 
Progress (2): 8.9 kB | 17 kB
Progress (2): 8.9 kB | 20 kB
Progress (2): 8.9 kB | 21 kB
                            
Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml (21 kB at 159 kB/s)
Downloaded from apache.snapshots: https://repository.apache.org/snapshots/org/apache/maven/plugins/maven-metadata.xml (8.9 kB at 61 kB/s)
[INFO]
[INFO] ----------------------< org.apache.doris:fe-core >----------------------
[INFO] Building Doris FE Core 1.2-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] Cache is disabled on project level for org.apache.doris:fe-core
[INFO]
[INFO] --- checkstyle:3.1.2:check (default-cli) @ fe-core ---
[INFO] Starting audit...
Audit done.
[INFO] You have 0 Checkstyle violations.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  41.171 s
[INFO] Finished at: 2026-04-17T05:45:08+03:00
[INFO] ------------------------------------------------------------------------
    - orb: Target system: Darwin; Target arch: arm64
Python 3.14.3
Check JAVA version
    - orb: Target system: Darwin; Target arch: arm64
Python 3.14.3
Check JAVA version
- Behavior changed: Yes (stricter/clearer validation for misaligned base RANGE partitions)
- Does this need documentation: No
hakanuzum added a commit to hakanuzum/doris that referenced this pull request Apr 17, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#62535

Problem Summary: Update MTMV hour-offset regression suites to reflect the alignment requirement between base RANGE partition boundaries and the rolled-up (shifted+truncated) buckets, and add coverage for edge cases (DATETIMEV2 fractional boundaries; TIMESTAMPTZ explicitly unsupported).

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - orb: [INFO] Scanning for projects...
[INFO] Loading cache configuration from /Users/hakanuzum/Desktop/Work/Personal/doris/fe/.mvn/maven-build-cache-config.xml
[INFO] Using XX hash algorithm for cache
[INFO] ------------------------------------------------------------------------
[INFO] Detecting the operating system and CPU architecture
[INFO] ------------------------------------------------------------------------
[INFO] os.detected.name: osx
[INFO] os.detected.arch: aarch_64
[INFO] os.detected.bitness: 64
[INFO] os.detected.version: 15.7
[INFO] os.detected.version.major: 15
[INFO] os.detected.version.minor: 7
[INFO] os.detected.classifier: osx-aarch_64
[INFO]
[INFO] ----------------------< org.apache.doris:fe-core >----------------------
[INFO] Building Doris FE Core 1.2-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] Cache is disabled on project level for org.apache.doris:fe-core
[INFO]
[INFO] --- checkstyle:3.1.2:check (default-cli) @ fe-core ---
[INFO] Starting audit...
Audit done.
[INFO] You have 0 Checkstyle violations.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.041 s
[INFO] Finished at: 2026-04-17T05:45:20+03:00
[INFO] ------------------------------------------------------------------------
    - orb: Target system: Darwin; Target arch: arm64
Python 3.14.3
Check JAVA version
    - orb: Target system: Darwin; Target arch: arm64
Python 3.14.3
Check JAVA version
- Behavior changed: No (tests only)
- Does this need documentation: No
@hakanuzum
Copy link
Copy Markdown
Author

Pushed fixes on top of the PR head:

  • Unwrap leading CAST in date_trunc(date_add/date_sub(...)) parsing (factory + refresh inverse-offset + expr service)
  • Clearer error for misaligned base RANGE partition boundaries (alignment requirement)
  • Fix FE checkstyle import ordering
  • Update mtmv_p0 regression suites to use aligned base partition boundaries; add DATETIMEV2 microsecond upper-bound case and explicit TIMESTAMPTZ unsupported case

Local (OrbStack ubuntu) checks:

  • cd fe && mvn checkstyle:check -pl fe-core ✅
  • ./run-fe-ut.sh --run org.apache.doris.mtmv.MTMVRelatedPartitionDescRollUpGeneratorTest ✅
  • ./run-fe-ut.sh --run org.apache.doris.mtmv.MTMVPlanUtilTest ✅

/review
run buildall

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Findings

  • MTMVPartitionExprDateTruncDateAddSub only models the new expression shape as (timeUnit, offsetHours). That makes casted forms like date_trunc(date_add(cast(k2 as date), INTERVAL 3 HOUR), 'day') behave as if the cast were absent when Doris builds partition lineage and when it revalidates the MV definition in SCHEMA_CHANGE.
  • UpdateMvByPartitionCommand derives base-table refresh predicates from the same pure-shift assumption. For the new cast-preserving forms this reads the wrong source rows during partial refresh.
  • MTMVPartitionDefinition matches raw nested partition expressions back to SELECT outputs by bare slot name only. Qualified references like t1.k2 therefore do not round-trip correctly and joined same-name columns become falsely ambiguous.

Critical Checkpoints

  • Goal: Partially achieved. Simple uncasted date_add/date_sub(..., INTERVAL N HOUR) support is wired through analysis and tests, but the new cast-preserving and qualified raw-expression cases are still incorrect.
  • Scope: Focused on MTMV FE partition analysis, refresh, and rewrite paths.
  • Concurrency: No new concurrency or lock-order issue found in this PR.
  • Lifecycle / static init: No special lifecycle or static initialization issue found.
  • Configuration: No new configuration items added.
  • Compatibility: No FE-BE/storage-format compatibility change, but MV partition-info revalidation is weakened because distinct inner expressions with the same offset/unit are treated as equivalent.
  • Parallel code paths: Not handled consistently. Rollup/lineage building, refresh predicate generation, and raw-expression resolution do not all preserve the same semantics for casted and qualified expressions.
  • Special checks: The new expression-shape guards exist, but they do not protect the cast/qualified cases above.
  • Test coverage: Added unit/regression coverage is good for the basic uncasted hour-offset path and serialization, but it misses cast-sensitive rollup/refresh correctness and qualified raw partition expressions.
  • Test result changes: New tests look internally consistent; no .out artifacts were involved.
  • Observability: No additional observability requirement identified.
  • Transaction / persistence / data writes: Partial refresh can select the wrong base-table slice for casted hour-offset expressions, which is a correctness issue for MV contents.
  • FE-BE variable passing: Not applicable here.
  • Performance: No major performance concern found beyond the correctness issues above.

Overall opinion: request changes.

hakanuzum added a commit to hakanuzum/doris that referenced this pull request Apr 17, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#62535

Problem Summary: Hour-offset MTMV partition expressions like date_trunc(date_add/sub(col, INTERVAL N HOUR), 'day') fail when base table RANGE partitions are aligned to UTC-midnight boundaries (00:00-00:00) because one base partition can overlap two shifted roll-up buckets. This change allows a single base range partition to map to multiple MTMV roll-up partitions, enabling UTC-midnight base tables to build and refresh local-day MTMVs.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - orb: [INFO] Scanning for projects...
[INFO] Loading cache configuration from /Users/hakanuzum/Desktop/Work/Personal/doris/fe/.mvn/maven-build-cache-config.xml
[INFO] Using XX hash algorithm for cache
[INFO] ------------------------------------------------------------------------
[INFO] Detecting the operating system and CPU architecture
[INFO] ------------------------------------------------------------------------
[INFO] os.detected.name: osx
[INFO] os.detected.arch: aarch_64
[INFO] os.detected.bitness: 64
[INFO] os.detected.version: 15.7
[INFO] os.detected.version.major: 15
[INFO] os.detected.version.minor: 7
[INFO] os.detected.classifier: osx-aarch_64
[INFO]
[INFO] ----------------------< org.apache.doris:fe-core >----------------------
[INFO] Building Doris FE Core 1.2-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] Cache is disabled on project level for org.apache.doris:fe-core
[INFO]
[INFO] --- checkstyle:3.1.2:check (default-cli) @ fe-core ---
[INFO] Starting audit...
Audit done.
[INFO] You have 0 Checkstyle violations.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  43.380 s
[INFO] Finished at: 2026-04-17T18:34:56+03:00
[INFO] ------------------------------------------------------------------------
    - orb: Target system: Darwin; Target arch: arm64
Python 3.14.3
Check JAVA version
- Behavior changed: Yes (MTMV hour-offset rollup no longer requires aligned base partition boundaries)
- Does this need documentation: No
@hakanuzum
Copy link
Copy Markdown
Author

Added support for UTC-midnight base partitions (1-to-N rollup mapping):

  • MTMVPartitionExprService: new generateRollUpPartitionKeyDescs() default API
  • MTMVRelatedPartitionDescRollUpGenerator: map one base range partition to multiple rollup buckets
  • MTMVPartitionExprDateTruncDateAddSub: generate all overlapped shifted+truncated buckets instead of requiring boundary alignment
  • FE UT: MTMVRelatedPartitionDescRollUpGeneratorTest#testRollUpRangeDateAddHourWithUtcMidnightBasePartitions

Local (OrbStack ubuntu):

  • cd fe && mvn checkstyle:check -pl fe-core ✅
  • ./run-fe-ut.sh --run org.apache.doris.mtmv.MTMVRelatedPartitionDescRollUpGeneratorTest ✅

/review
run buildall

@hakanuzum
Copy link
Copy Markdown
Author

/review

Copy link
Copy Markdown
Author

@hakanuzum hakanuzum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

@github-actions
Copy link
Copy Markdown
Contributor

OpenCode automated review failed and did not complete.

Error: Review step was failure (possibly timeout or cancelled)
Workflow run: https://github.com/apache/doris/actions/runs/24573400793

Please inspect the workflow logs and rerun the review after the underlying issue is resolved.

@github-actions
Copy link
Copy Markdown
Contributor

OpenCode automated review failed and did not complete.

Error: Review step was failure (possibly timeout or cancelled)
Workflow run: https://github.com/apache/doris/actions/runs/24574404715

Please inspect the workflow logs and rerun the review after the underlying issue is resolved.

hakanuzum added a commit to hakanuzum/doris that referenced this pull request Apr 18, 2026
### What problem does this PR solve?

Issue Number: close apache#62535

Problem Summary: Add test coverage for UTC-midnight aligned base partitions with hour-offset MTMV partition expressions. This validates the 1-to-N partition mapping implementation.

### Release note

None

### Check List (For Author)

- Test: Regression test
    - Added new test case for UTC-midnight partition scenario
- Behavior changed: No
- Does this need documentation: No
hakanuzum added a commit to hakanuzum/doris that referenced this pull request Apr 18, 2026
…TC-midnight base partitions

### What problem does this PR solve?

Issue Number: close apache#62535

Problem Summary: Implement 1-to-N partition mapping to support hour-offset MTMV partition expressions (like `date_trunc(date_add(col, INTERVAL N HOUR), 'day')`) when base table partitions are aligned to UTC-midnight boundaries. Previously, a single base partition that spans two roll-up buckets would fail; now it correctly maps to multiple MTMV partitions.

### Release note

Feature: Support hour-offset MTMV partition expressions with UTC-midnight base partitions. Users can now create materialized views with expressions like `date_trunc(date_add(col, INTERVAL 3 HOUR), 'day')` even when base table uses UTC-midnight aligned partitions.

### Check List (For Author)

- Test: Regression test + Unit test
- Behavior changed: Yes (previously failed with alignment error, now succeeds with 1-to-N mapping)
- Does this need documentation: Yes
@hakanuzum hakanuzum force-pushed the feat/mtmv-date-add-interval-partition-v2 branch from 81576e3 to 5bd204a Compare April 18, 2026 10:42
hakanuzum added a commit to hakanuzum/doris that referenced this pull request Apr 18, 2026
…TC-midnight base partitions

Issue Number: close apache#62535

Problem Summary: Implement 1-to-N partition mapping to support hour-offset MTMV partition expressions (like `date_trunc(date_add(col, INTERVAL N HOUR), 'day')`) when base table partitions are aligned to UTC-midnight boundaries. Previously, a single base partition that spans two roll-up buckets would fail; now it correctly maps to multiple MTMV partitions.

Feature: Support hour-offset MTMV partition expressions with UTC-midnight base partitions. Users can now create materialized views with expressions like `date_trunc(date_add(col, INTERVAL 3 HOUR), 'day')` even when base table uses UTC-midnight aligned partitions.

- Test: Regression test + Unit test
- Behavior changed: Yes (previously failed with alignment error, now succeeds with 1-to-N mapping)
- Does this need documentation: Yes
@hakanuzum hakanuzum closed this Apr 18, 2026
@hakanuzum hakanuzum force-pushed the feat/mtmv-date-add-interval-partition-v2 branch from 410a331 to 4c421c0 Compare April 18, 2026 10:46
@hakanuzum hakanuzum reopened this Apr 18, 2026
@hakanuzum hakanuzum closed this Apr 18, 2026
@hakanuzum hakanuzum force-pushed the feat/mtmv-date-add-interval-partition-v2 branch from 410a331 to 4c421c0 Compare April 18, 2026 10:55
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.

[Feature] Support arbitrary scalar functions in materialized view partition expressions (e.g. CONVERT_TZ, DATE_ADD, CAST)

2 participants