Conversation
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
run buildall |
TPC-H: Total hot run time: 26843 ms |
TPC-DS: Total hot run time: 168011 ms |
yujun777
force-pushed
the
ivm-yj-1
branch
4 times, most recently
from
March 19, 2026 09:52
ce07174 to
5b0f7f2
Compare
Contributor
Author
|
run buildall |
Contributor
Author
|
run buildall |
TPC-H: Total hot run time: 26660 ms |
TPC-DS: Total hot run time: 168858 ms |
Contributor
FE UT Coverage ReportIncrement line coverage |
Contributor
Author
|
run buildall |
TPC-H: Total hot run time: 26893 ms |
TPC-DS: Total hot run time: 167693 ms |
Contributor
Author
|
run buildall |
TPC-H: Total hot run time: 26963 ms |
TPC-DS: Total hot run time: 169448 ms |
Contributor
Author
|
run buildall |
Contributor
Author
|
run buildall |
TPC-H: Total hot run time: 26586 ms |
TPC-DS: Total hot run time: 168564 ms |
Contributor
FE UT Coverage ReportIncrement line coverage |
Contributor
Author
|
run buildall |
Problem: murmur_hash3_64 implements PropagateNullable, so any NULL group key argument makes the entire hash return NULL. This causes different groups with NULL keys to collide (e.g., (NULL,'a') and (NULL,'b') both produce row_id=NULL), leading to incorrect incremental refresh results. Key changes: - Replace direct hash(keys...) with null-safe pattern: hash(ifnull(cast(k AS VARCHAR),''), cast(isnull(k) AS VARCHAR), ...) per key - Add MurmurHash364(List<Expression>) constructor for cleaner list-based construction - Remove unused IvmUtil.newIvmCountColumnDefinition() - Update IVM AGENTS.md with null-safe row_id documentation Unit Test: - IvmUtilTest: 7 new tests verifying expression tree structure and non-nullability - All 99 existing IVM FE unit tests pass Regression Test: - test_ivm_agg_4: Parts 16-18 covering single/multiple NULL group keys and empty-string vs NULL distinction
…ions Previously IVM rejected compound expressions like SUM(v1+v2) or MIN(v1*2) inside aggregate functions, requiring bare column Slots only. This relaxes the constraint to accept arbitrary expressions as aggregate arguments. Key changes: - IvmAggMeta.AggTarget: exprSlots (List<Slot>) -> exprArgs (List<Expression>) - IvmNormalizeMtmv: removed instanceof Slot check in buildHiddenStateForAgg - IvmAggDeltaStrategy: widened helper method params from Slot to Expression - Renamed all misleading XXXSlot variables/methods to XXXArg where type is Expression Unit Test: IvmNormalizeMtmvTest (25), IvmAggDeltaStrategyTest (25), all 103 IVM FE tests pass Regression Test: all 7 IVM regression suites pass
…code Replace bare "SUM"/"COUNT"/"MIN"/"MAX" strings used as hidden state slot keys with a type-safe StateKey enum in IvmAggMeta. This prevents typos and provides compile-time safety. Also extract addHiddenSumAndCount() and addHiddenAlias() helper methods in IvmNormalizeMtmv to eliminate SUM/AVG code duplication. Key changes: - Add IvmAggMeta.StateKey enum with SUM, COUNT, MIN, MAX values - Change AggTarget.hiddenStateSlots from Map<String,Slot> to Map<StateKey,Slot> - Update all callsites in IvmAggDeltaStrategy and IvmNormalizeMtmv - Add DELMIN/DELMAX as private static final String constants (transient keys) - Extract addHiddenSumAndCount() and addHiddenAlias() in IvmNormalizeMtmv - Update IvmNormalizeMtmvTest to use StateKey Unit Test: 103 IVM FE unit tests pass Regression Test: all 7 IVM suites pass
When an IVM INCREMENTAL refresh fails because a deleted row equals
the current MIN or MAX aggregate value, the assert_true guard fires
at runtime. Previously this was caught as a generic
INCREMENTAL_EXECUTION_FAILED reason, making it hard to distinguish
from real execution errors in logs and task error messages.
Key changes:
- IvmRefreshManager.doRefreshInternal() inspects the caught exception
message for the boundary guard marker ("IVM: deleted row may be
current") and sets IvmFallbackReason.MIN_MAX_BOUNDARY_HIT, which
was defined but never used before
- Boundary hits are logged at INFO level (expected path) while other
execution failures remain at WARN level
- Update regression test error-message assertions (Parts 4 and 9) to
also check for MIN_MAX_BOUNDARY in the reason string
Unit Test: 103 FE unit tests pass; 7/7 IVM regression suites pass
### What problem does this PR solve? Issue Number: close #xxx Problem Summary: Previously, IVM (Incremental View Maintenance) rejected materialized views with GROUP BY but no aggregate functions, throwing "GROUP BY without aggregate functions is not supported for IVM". This is unnecessarily restrictive because the unconditionally-injected hidden column `__DORIS_IVM_AGG_COUNT_COL__` alone is sufficient to track group membership for incremental maintenance. A bare GROUP BY is semantically equivalent to SELECT DISTINCT, and the delta/apply paths already handle empty aggTargets lists correctly. ### Release note Support bare GROUP BY (SELECT DISTINCT) queries in IVM materialized views. ### Check List (For Author) - Test: Unit Test (IvmNormalizeMtmvTest) + Regression test (test_ivm_agg_5) - Behavior changed: Yes — previously rejected bare GROUP BY with AnalysisException, now accepted - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ssion tests ### What problem does this PR solve? Issue Number: N/A Problem Summary: IVM agg regression suites (test_ivm_agg_1~3, 5) only verified MV output after COMPLETE refresh, leaving INCREMENTAL refresh code paths untested. Also, test_ivm_agg_5 had a logic flaw in Part 1 where consecutive INCREMENTAL refreshes inflated group counts, preventing group deletion from triggering correctly. ### Release note None ### Check List (For Author) - Test: Regression test — all 8 suites under mtmv_p0/ivm pass - Behavior changed: No - Does this need documentation: No Key changes: - test_ivm_agg_1.groovy: Add 6 order_qt_* assertions after INCREMENTAL refreshes - test_ivm_agg_2.groovy: Add 8 order_qt_* assertions after INCREMENTAL refreshes - test_ivm_agg_3.groovy: Add 4 order_qt_* assertions after INCREMENTAL refreshes - test_ivm_agg_5.groovy: Redesign Part 1 into 3 isolated Scenarios (A/B/C), each starting from a fresh COMPLETE to keep counts accurate; redesign Part 2 to combine delete+insert in one batch before a single INCREMENTAL; fix Scenario B comment errors - Regenerate test_ivm_agg_1~3.out and generate new test_ivm_agg_5.out
…S.md ### What problem does this PR solve? Issue Number: N/A Problem Summary: The binlog_op mocking guide for IVM regression tests was only in an untracked AGENTS.md under the regression-test directory. Merge it into the committed FE IVM AGENTS.md so it is preserved and visible to all contributors, with an additional note about the COMPLETE-before-delete requirement for correct group deletion testing. ### Release note None ### Check List (For Author) - Test: No need to test (documentation only) - Behavior changed: No - Does this need documentation: No
Rewrite the IVM FE unit tests that still depended on JMockit so FE test compilation works with the current test dependencies. Key changes: - replace JMockit usage in IvmDeltaExecutorTest with Mockito static mocks - rewrite RefreshMTMVInfoAnalyzeTest to use Mockito for Env and catalog setup - migrate the remaining IVM FE tests away from JMockit imports and expectations Unit Test: - mvn test -pl fe-core -Dtest="RefreshMTMVInfoAnalyzeTest" -Dmaven.build.cache.enabled=false - mvn test -pl fe-core -Dtest="IvmDeltaExecutorTest,IvmDeltaRewriterTest,IvmSimpleScanDeltaStrategyTest,IvmRefreshManagerTest" -Dmaven.build.cache.enabled=false
…anagerTest ### What problem does this PR solve? Problem Summary: IvmRefreshManagerTest still used JMockit annotations (@mocked, Expectations) which are not available as a dependency, causing FE compilation failure. ### Release note None ### Check List (For Author) - Test: No need to test (build fix only, replacing mock framework usage) - Behavior changed: No - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
### What problem does this PR solve? Issue Number: close #xxx Problem Summary: IVM (Incremental View Maintenance) was creating redundant hidden columns in the MV schema. For several aggregate types, the visible column already stores the same value as the hidden column, wasting storage and adding unnecessary complexity: - COUNT(*): hidden COUNT duplicated the global group count - COUNT(expr): hidden COUNT duplicated the visible COUNT(expr) - SUM: hidden SUM duplicated the visible SUM value - MIN/MAX: hidden MIN/MAX duplicated the visible extremal value This commit removes these redundant hidden columns. The delta apply logic now reads old state from the visible column instead. Only genuinely needed hidden columns are retained: - SUM/MIN/MAX: hidden COUNT (for assertNonNegative guard and null logic) - AVG: hidden SUM + COUNT (visible is AVG, not SUM or COUNT) Additional cleanup: - Inline addHiddenSumAndCount (only called once for AVG) - Remove hasIvmHiddenOutputInOutputs/isIvmHiddenOutput private methods - Simplify group key resolution to direct Slot casting - Add stateColumnName(StateKey) helper to AggTarget - Fix toColumn() bug in IvmDeltaTestBase (isVisible/isKey params swapped) - Update class Javadoc with accurate plan shape ### Release note None ### Check List (For Author) - Test: Unit Test (90 IVM FE UTs + 24 CreateMTMVCommandTest all pass) and Regression test (8 IVM regression tests all pass) - Behavior changed: No (internal schema optimization, no user-visible change) - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ey with AggType
### What problem does this PR solve?
Issue Number: close #xxx
Problem Summary:
The IVM (Incremental View Maintenance) code had two redundant abstractions:
1. AggType enum had separate COUNT_STAR and COUNT_EXPR values, but the only
difference is whether exprArgs is empty. Merging them into a single COUNT
type with an isCountStar() helper simplifies all switch statements.
2. StateKey enum {SUM, COUNT, MIN, MAX} was a strict subset of AggType
{COUNT, SUM, AVG, MIN, MAX} (AVG is never used as a hidden-state key).
Eliminating StateKey removes an unnecessary indirection layer.
3. caseWhenExprNotNull was renamed to ifExprNotNull since it generates an
IF expression, not a CASE WHEN.
### Release note
None
### Check List (For Author)
- Test: Unit Test (90 IVM FE UTs + 24 CreateMTMVCommandTest) and Regression test (8 IVM suites)
- Behavior changed: No
- Does this need documentation: No
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix compilation and checkstyle errors caused by upstream's TableNameInfo class relocation (org.apache.doris.info → org.apache.doris.catalog.info) and duplicate TStorageType import from conflict resolution. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
run buildall |
…ustness ### What problem does this PR solve? Problem Summary: 1. Remove empty if-block in buildHiddenStateForAgg COUNT branch — neither COUNT(*) nor COUNT(expr) adds hidden columns, so the if was dead code. 2. Use Count.isCountStar() instead of Count.isStar() when determining exprArgs. isCountStar() also covers COUNT() and COUNT(literal) forms, making the code robust against optimizer rewrites like COUNT(*)->COUNT(1). ### Release note None ### Check List (For Author) - Test: Unit Test (IvmNormalizeMtmvTest, IvmAggDeltaStrategyTest, CreateMTMVCommandTest all pass) - Behavior changed: No - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
FE Regression Coverage ReportIncrement line coverage |
…to zero
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
When all non-null rows contributing to a MIN/MAX aggregate are deleted
(hidden non-null count drops to 0), the boundary guard assertion
(assert_true) would incorrectly fire because the deleted extremal value
equals the current extreme. This caused unnecessary COMPLETE fallback.
This change:
- Adds newCount==0 as the first disjunct in the guard OR condition,
bypassing the boundary check when count is zero (no boundary to protect)
- Replaces nested IF merge logic with CASE WHEN for clarity:
CASE WHEN newCount=0 THEN NULL
WHEN old IS NULL THEN deltaInsert
WHEN deltaInsert IS NULL THEN old
ELSE LEAST/GREATEST END
- Uses flat Or(ImmutableList.of(...)) instead of nested binary Or
- Updates method Javadoc to document the four-way guard condition
- Adds regression tests (test_ivm_agg_6) for two scenarios:
A) Delete all rows: cnt=0, min/max=NULL
B) Delete last non-null row with NULL rows remaining: min/max=NULL
### Release note
None
### Check List (For Author)
- Test: Regression test (test_ivm_agg_6), FE unit test pass
- Behavior changed: No
- Does this need documentation: No
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* [improvement](fe) Add IVM create and alter validation for MTMV (#5) Issue Number: close #xxx Problem Summary: 1. Remove redundant pre-analysis in IVM analyzeQuery - single analyzeQueryInternal call 2. Unify IVM base table validation error messages (AGG_KEYS vs UNIQUE without MOW) 3. Add excluded_trigger_tables support in IvmNormalizeMtmv (transient row-id for excluded tables) 4. Block ALTER MTMV refresh method to/from INCREMENTAL 5. Validate base table models when ALTER MTMV excluded_trigger_tables 6. Extract MTMVPropertyUtil.parseTableNameInfos utility 7. Add comprehensive unit tests for all validation paths * [fix](fe) Fix IVM ExprId collision by reusing parser StatementContext ### What problem does this PR solve? Issue Number: close #xxx Problem Summary: Commit 71a3086 introduced a new StatementContext in analyzeQueryInternal() and restored the original (parser-created) StatementContext in the finally block. This caused ExprId collisions during IVM INCREMENTAL refresh because the parser StatementContext has a much smaller ExprId counter than the analysis StatementContext, and IvmRefreshManager.doRefreshInternal() reads exprIdStart from the ConnectContext's StatementContext after analysis. The fix reverts to the pre-71a3086f pattern: reuse ctx.getStatementContext() (the parser-created StatementContext) directly for analysis instead of creating a new one. This way all ExprId allocations accumulate in the same StatementContext that doRefreshInternal() later reads. ### Release note None ### Check List (For Author) - Test: Regression test (test_ivm_agg_2) - Behavior changed: No - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [fix](fe) Fix buildRowId to compute proper row-id for excluded trigger tables ### What problem does this PR solve? Issue Number: close #xxx Problem Summary: buildRowId() short-circuited to UuidNumeric() for excluded trigger tables, losing the deterministic row-id (hash of unique keys) for MOW and non-MOW UNIQUE_KEYS tables. The fix removes the early return and only uses the isExcludedTriggerTable flag to suppress AnalysisException for unsupported table types (AGG_KEYS etc.), while UNIQUE_KEYS tables always compute buildRowIdHash(keySlots) regardless of exclusion status. ### Release note None ### Check List (For Author) - Test: Unit Test (IvmNormalizeMtmvTest) - Behavior changed: No - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [test](fe) Update IvmNormalizeMtmvTest for excluded MOW table row-id fix ### What problem does this PR solve? Issue Number: close #xxx Problem Summary: Update testExcludedMowTableUsesTransientRowId to expect deterministic hash-based row-id (Cast expression) instead of UuidNumeric for excluded MOW tables, matching the fix in buildRowId(). ### Release note None ### Check List (For Author) - Test: Unit Test (IvmNormalizeMtmvTest - 27 tests pass) - Behavior changed: No - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [fix](fe) Refine ALTER MTMV refresh method compatibility rules ### What problem does this PR solve? Issue Number: close #xxx Problem Summary: The ALTER MTMV refresh method validation was too restrictive (blocking all changes to/from INCREMENTAL) or too permissive in some cases. The new rules: - COMPLETE <-> INCREMENTAL: forbidden (must recreate MV) - COMPLETE/INCREMENTAL -> AUTO: allowed - AUTO -> COMPLETE/INCREMENTAL: forbidden (must recreate MV) - Same method (no-op): allowed ### Release note None ### Check List (For Author) - Test: Regression test - Behavior changed: Yes (COMPLETE/INCREMENTAL to AUTO now allowed) - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * opt code * [test](fe) Isolate CreateMTMVCommandTest statement context ### What problem does this PR solve? Issue Number: None Related PR: None Problem Summary: CreateMTMVCommandTest reused the same StatementContext across multiple statements, so table and excluded_trigger_tables state leaked between test cases and caused false incremental MV validation failures. This change resets the statement context for each statement in the test and adds the missing LinkedHashSet import required by StatementContext. ### Release note None ### Check List (For Author) - Test: FE unit test - ./run-fe-ut.sh --run org.apache.doris.mtmv.ivm.IvmAggDeltaStrategyTest,org.apache.doris.mtmv.ivm.IvmDeltaExecutorTest,org.apache.doris.mtmv.ivm.IvmDeltaRewriterTest,org.apache.doris.mtmv.ivm.IvmRefreshManagerTest,org.apache.doris.mtmv.ivm.IvmSimpleScanDeltaStrategyTest,org.apache.doris.mtmv.ivm.IvmUtilTest,org.apache.doris.nereids.rules.rewrite.IvmNormalizeMtmvTest,org.apache.doris.nereids.trees.plans.CreateMTMVCommandTest,org.apache.doris.catalog.ShowCreateMTMVTest - Behavior changed: No - Does this need documentation: No * [fix](fe) Fix TableNameInfo imports after rebasing IVM branch ### What problem does this PR solve? Issue Number: None Related PR: None Problem Summary: Rebase onto the latest yujun777/ivm left several FE IVM files importing org.apache.doris.info.TableNameInfo while the current base branch provides the type in org.apache.doris.catalog.info.TableNameInfo. This fixes the stale imports so the rebased branch compiles and the targeted IVM FE tests run successfully again. ### Release note None ### Check List (For Author) - Test: Unit Test - org.apache.doris.mtmv.ivm.IvmAggDeltaStrategyTest - org.apache.doris.mtmv.ivm.IvmDeltaExecutorTest - org.apache.doris.mtmv.ivm.IvmDeltaRewriterTest - org.apache.doris.mtmv.ivm.IvmRefreshManagerTest - org.apache.doris.mtmv.ivm.IvmSimpleScanDeltaStrategyTest - org.apache.doris.mtmv.ivm.IvmUtilTest - org.apache.doris.nereids.rules.rewrite.IvmNormalizeMtmvTest - org.apache.doris.nereids.trees.plans.CreateMTMVCommandTest - org.apache.doris.catalog.ShowCreateMTMVTest - Behavior changed: No - Does this need documentation: No * [fix](fe) Use deterministic row id for excluded AGG_KEYS tables ### What problem does this PR solve? Issue Number: None Related PR: None Problem Summary: IVM normalization treated excluded AGG_KEYS base tables as transient-row-id scans and generated uuid_numeric() row ids. This changed excluded AGG_KEYS row identity across refreshes and did not follow the base table aggregate keys. Fix buildRowId to hash base-schema key columns for excluded AGG_KEYS tables, and add focused tests to verify the row id is deterministic and excludes non-key value columns. ### Release note None ### Check List (For Author) - Test: Unit Test - org.apache.doris.mtmv.ivm.IvmAggDeltaStrategyTest - org.apache.doris.mtmv.ivm.IvmDeltaExecutorTest - org.apache.doris.mtmv.ivm.IvmDeltaRewriterTest - org.apache.doris.mtmv.ivm.IvmRefreshManagerTest - org.apache.doris.mtmv.ivm.IvmSimpleScanDeltaStrategyTest - org.apache.doris.mtmv.ivm.IvmUtilTest - org.apache.doris.nereids.rules.rewrite.IvmNormalizeMtmvTest - org.apache.doris.nereids.trees.plans.CreateMTMVCommandTest - org.apache.doris.catalog.ShowCreateMTMVTest - Behavior changed: Yes (excluded AGG_KEYS row-id generation is now deterministic on agg keys) - Does this need documentation: No * fix comment * fix comment * opt code --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ages
### What problem does this PR solve?
Problem Summary:
1. Remove dead code in IvmNormalizeMtmv.buildRowId() — the isExcludedTriggerTable
branch at lines 503-505 was unreachable because all KeysType cases (UNIQUE_KEYS,
DUP_KEYS, AGG_KEYS) are already handled above it.
2. Improve the error message in AlterMTMVRefreshInfo.validateRefreshMethodCompat()
when attempting to alter the refresh method of an INCREMENTAL materialized view,
making it clearer that the operation is not allowed.
### Release note
None
### Check List (For Author)
- Test: Regression test / Unit Test
- FE UT: 94/94 IVM tests passed
- Regression: 10/10 IVM suites passed (mtmv_p0/ivm)
- Behavior changed: No
- Does this need documentation: No
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
run buildall |
Contributor
FE Regression Coverage ReportIncrement line coverage |
### What problem does this PR solve? Issue Number: close #xxx Problem Summary: Implements the core multi-bundle delta plan generation for IVM incremental refresh. This enables producing one delta command bundle per base table that has pending changes, with correct TSO snapshot binding across all scans in the normalized plan. Changes: - IvmStreamRef: Replaced streamType/consumerId/properties with consumedTso (persisted) and latestTso (transient). Added isUpToDate(). Deleted StreamType enum. - OlapTable: Added getVisibleTso() mock (delegates to getVisibleVersion). - LogicalOlapScan: Added tso (default -1) and isDelta (default false) fields, with withTso()/withIsDelta() methods. Both participate in equals(). - IvmDeltaRewriter: Complete rewrite with generateDeltaPlans() multi-bundle logic, rewriteOlapScans() helper, replaceWithDelta() mock. Uses rewriteDownShortCircuit + AtomicInteger for deterministic scan traversal. TSO binding: j<i → latestTso (v2), j>i → consumedTso (v1). Includes latestTso >= consumedTso invariant check. - IvmSimpleScanDeltaStrategy: isDelta check — non-delta scans skip dml_factor. - IvmAggDeltaStrategy: ctx made final, set via constructor (single-use). - IvmRefreshManager: Empty bundles = success (no-op, all tables up to date). - IvmDeltaRewriteContext: Added baseTableStreams field. ### Release note None ### Check List (For Author) - Test: Unit Test (109 IVM tests pass: 21 rewriter, 25 agg strategy, 14 simple strategy, 28 normalize, 7 util, 10 refresh manager, 4 executor) - Behavior changed: No - Does this need documentation: No Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
run buildall |
… latestTso reading
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Implements Steps 6-7 of the multi-bundle IVM plan:
Step 6 - runningIvmRefresh crash recovery flag:
- Add runningIvmRefresh boolean to IvmInfo with @SerializedName("rr")
- Add ALTER_IVM_INFO editlog op type with full AlterMTMV persistence path
- In IvmRefreshManager: set flag=true before bundle execution, clear after
success with consumedTso advance in one atomic editlog write
- On failure: leave flag set so next task detects and falls back to COMPLETE
- In MTMVTask: detect flag on COMPLETE refresh entry, capture pre-refresh
TSOs, reset state after successful full refresh
- MTMV.alterIvmInfo() and getIvmInfo() use writeMvLock for thread safety
Step 7 - latestTso reading and baseTableStreams passing:
- populateLatestTso() reads OlapTable.getVisibleTso() for each base table
- ensureBaseTableStreamsInitialized() lazily populates from MTMV relation
metadata on first incremental refresh (handles empty map from MTMV creation)
- Pass baseTableStreams to IvmDeltaRewriteContext for TSO binding
- Guard advanceConsumedTso: only advance if latestTso >= consumedTso to
prevent regression when table resolution fails
### Release note
None
### Check List (For Author)
- Test: Unit Test (71 tests pass: IvmRefreshManager 17, IvmDeltaRewriter 21, IvmAggDeltaStrategy 25, AlterMTMV 8) + Regression test (10/10 IVM tests pass)
- Behavior changed: No
- Does this need documentation: No
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
run buildall |
Contributor
FE Regression Coverage ReportIncrement line coverage |
69 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)