englefly commented on PR #68282:
URL: https://github.com/apache/doris/pull/68282#issuecomment-5862642462

   Status of the three P2 findings of review `5300244675` (head `4001d5d4532`, 
no code change in this round — analysis and reproduction evidence only, replies 
are in the three inline threads).
   
   **Verified on a local FE + BE cluster, exact numbers**
   
   - MF-1 (merge-key base index): `UNIQUE KEY(k)`, `TRUNCATE`, then two 
transactions writing `k=1` -> `SELECT count(*)` reports **1**, `EXPLAIN` 
reports **cardinality=2**, `SHOW TABLE STATS` shows `updated_rows=2, 
row_count=0`. The delta is the sum of `rowset_meta.num_rows()` over 
transactions, i.e. physical rows, which a merge-key base index cannot use as a 
logical cardinality.
   - MF-3(b) (rollup published after the reset): `TRUNCATE`, then `ADD ROLLUP 
r_late (k1, v)`, then 3 rows -> `EXPLAIN SELECT k1, v FROM t3 INDEX r_late` 
reports **cardinality=2**, i.e. `-1 + 3`, while the base index scan reports 3.
   
   **Confirmed in code, not reproduced**
   
   - MF-2 (filtered synchronous MV): `MaterializedIndexMeta.whereClause` is 
persisted, `OlapTableSink` / `BindSink.createSyncMvWhereClause()` only write 
the rows which satisfy the predicate, and `MaterializedViewHandler` rejects a 
plain prefix projection of a duplicate key table *unless* it has a where 
clause. My local `CREATE MATERIALIZED VIEW ... WHERE` did not attach a filtered 
index to the base table (it went to the async path), so I have no live numbers; 
I asked in the thread for the DDL used to create one.
   - MF-3(a) (rollup analysed on its own): follows from `update()` advancing 
the base baseline only for a job which carries the base index row count, while 
a rollup-only analysis publishes the rollup count against the same base 
baseline -> `150 + (150 - 100) = 200`.
   
   **Plan when the design is settled** (single commit, so the provenance rules 
are stated once)
   
   1. `never add a delta to UNKNOWN_ROW_COUNT` in `getRowCountWithDeltaRows()`.
   2. Classify the base index by key semantics as well: a `UNIQUE`/`AGG` base 
index must not use the physical delta as a logical row count.
   3. Require a null `whereClause()` before an index counts as row-preserving.
   4. Keep count and baseline per index (or record the baseline together with 
the index count that was published), instead of anchoring every index's delta 
at the base baseline.
   5. Tests for the four missing shapes: repeated full keys on a `UNIQUE` and 
an `AGG` base, a rollup added after the reset, a rollup-only analysis, and a 
filtered projection MV.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to