yujun777 commented on code in PR #68648:
URL: https://github.com/apache/doris/pull/68648#discussion_r4225349421


##########
fe/fe-core/src/main/java/org/apache/doris/catalog/MTMV.java:
##########
@@ -1619,6 +1621,58 @@ public Map<String, Map<MTMVRelatedTableIf, Set<String>>> 
calculatePartitionMappi
         return res;
     }
 
+    /**
+     * The list partition each base table of this MV has that takes the rows 
no other partition of it claims,
+     * by table, or none for a table that has no such partition.
+     *
+     * <p>Read once per mapping rather than per MV partition: the mapping 
describes every MV partition and the
+     * answer is the table's, not the partition's. The partition metadata is 
read without a lock, like the
+     * rest of the mapping this is part of.
+     */
+    private Map<MTMVRelatedTableIf, String> defaultListPartitionsOf() throws 
AnalysisException {
+        Map<MTMVRelatedTableIf, String> res = Maps.newHashMap();
+        for (MTMVRelatedTableIf pctTable : mvPartitionInfo.getPctTables()) {
+            if (!(pctTable instanceof OlapTable)) {
+                continue;
+            }
+            OlapTable olapTable = (OlapTable) pctTable;
+            if (!(olapTable.getPartitionInfo() instanceof ListPartitionInfo)) {
+                continue;
+            }
+            for (String partitionName : olapTable.getPartitionNames()) {
+                if 
(olapTable.getPartitionItemOrAnalysisException(partitionName).isDefaultPartition())
 {
+                    res.put(pctTable, partitionName);
+                    break;
+                }
+            }
+        }
+        return res;
+    }
+
+    /**
+     * One MV partition's mapping, with every base table's default list 
partition named in it.
+     *
+     * <p>Such a partition holds rows for every key its table can be read by, 
so it belongs to every MV
+     * partition that reads the table -- not only to the one its own key, the 
sentinel those rows were placed
+     * by, maps to. Naming it everywhere is what the read and the record have 
to agree on: the refresh reads
+     * the rows of it that belong to the MV partition being refreshed, and the 
partition is recorded among the
+     * ones that partition is read through, so an insert into it leaves that 
MV partition out of sync instead
+     * of changing nothing the MV compares.
+     */
+    private Map<MTMVRelatedTableIf, Set<String>> withDefaultListPartitions(
+            Map<MTMVRelatedTableIf, Set<String>> mapping, 
Map<MTMVRelatedTableIf, String> defaultListPartitions) {
+        if (defaultListPartitions.isEmpty()) {
+            return mapping;
+        }
+        Map<MTMVRelatedTableIf, Set<String>> res = Maps.newHashMap(mapping);
+        for (Entry<MTMVRelatedTableIf, String> entry : 
defaultListPartitions.entrySet()) {
+            Set<String> partitions = 
Sets.newHashSet(res.getOrDefault(entry.getKey(), Sets.newHashSet()));
+            partitions.add(entry.getValue());

Review Comment:
   An update on the multi-column half I called the next step: it turns out 
there is nothing to make position-aware, because that shape cannot be created.
   
   `PARTITION BY (d, k)` is rejected by the parser -- `mismatched input ',' 
expecting ')'` -- and `MTMVPartitionDefinition.partitionCol` carries a single 
column, so `getPartitionColumns()` is one column for every materialized view 
that can be built. The `getPartitionColumns().size() != 1` guard in 
`mvPartitionsToReadThrough` is therefore not a case left half answered but the 
shape to revisit if the grammar ever accepts several columns: at that point the 
key position of the base column among the MV's partition columns has to come 
from somewhere, and it is not in `BaseColInfo`, which is what the guard says.
   
   So the aliased-column case is what this thread had left, and it is fixed in 
0dbc4082600.
   



-- 
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