yujun777 commented on code in PR #68648:
URL: https://github.com/apache/doris/pull/68648#discussion_r4237073908
##########
fe/fe-core/src/main/java/org/apache/doris/mtmv/MTMVRewriteUtil.java:
##########
@@ -166,25 +231,46 @@ private static Set<String>
getMtmvPartitionsByRelatedPartitions(MTMV mtmv, MTMVR
}
Set<String> pctPartitions = entry.getValue();
for (String pctPartition : pctPartitions) {
- String mvPartition = relatedToMv.get(Pair.of(tableIf,
pctPartition));
- if (mvPartition != null) {
- res.add(mvPartition);
+ Set<String> mvPartitions = relatedToMv.get(Pair.of(tableIf,
pctPartition));
+ if (mvPartitions == null) {
+ // A partition the query reads that no MV partition is
mapped from -- one the partition
+ // mapping left out, an expired base partition for
instance -- is one the MV's rows say
+ // nothing about. With the union rewrite on it is taken
out of the MV plan and read from
+ // the base table, so the MV partitions the other base
partitions map to still answer the
+ // query and this one is passed over. Without it the MV
alone would answer, so no partition
+ // is answered for at all: the MV is not a candidate for
this query and the query is
+ // answered from the base table.
+ if (unionRewrite) {
Review Comment:
Fixed in 313be052543, now that the sets stay per table (905d45d79db): that
was what made the attempt I reported earlier trade one shape for the other, so
it was worth retrying rather than handing over.
A base partition the query reads that no MV partition of the plan is named
from is one the MV does not hold, and the per-table pass cannot reach it -- it
works from the mapping, which has no entry for it -- so the MV's own branch
answered alone and short of those rows. Adding the partition to the union alone
would not do, because the MV partitions the plan uses still hold the rows they
hold and the answer would count them twice; so the partitions the plan uses are
taken out and the query's partitions are read from the base table. A partition
the MV's own snapshots name for a partition the plan reads is left where it is,
since the MV does hold its rows and the validity pass decides about them.
Measured on the shape from my previous comment: the MV holds `2020-01-01 ->
1` and the query now returns exactly the base table's rows, `2020-01-01 -> 2`
and `2038-01-01 -> 1`. `partition_mv_rewrite` and `union_rewrite_grace_big` --
the two suites whose answers the earlier attempt disturbed -- pass, as does the
`mtmv_p0` set, and `PartitionCompensatorTest`'s two-table case now asserts each
table's own union set rather than the merged one.
--
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]
