mrhhsg opened a new pull request, #68279:
URL: https://github.com/apache/doris/pull/68279
### What problem does this PR solve?
Issue Number: None
Problem Summary: `SegmentIterator::_get_row_ranges_by_column_conditions()`
builds the condition row ranges from the whole segment, although `_row_bitmap`
at that point already carries the key-range and index pruning. The zone map /
bloom filter counters are therefore computed against rows that were pruned long
before. A point lookup shows it clearly: on a 200k row table, `SELECT COUNT(*)
FROM t WHERE k = 12345 AND v = 12345` reports
```
RowsKeyRangeFiltered: 199.999K (199999) -- one row left
RowsStatsFiltered: 183.616K (183616) -- but the zone map "filtered"
this many
RowsConditionsFiltered: 0
```
Start the condition ranges from the rows that are still alive, so the
counters only report what the index really pruned. Measured on a local cluster
with the query above:
| | before | after |
|---|---|---|
| `RowsKeyRangeFiltered` | 199999 | 199999 |
| `RowsStatsFiltered` | 183616 | 0 |
| rows returned | 1 | 1 |
A query without a key range (`WHERE v = 12345`) still reports
`RowsStatsFiltered: 183616`, so zone map pruning itself is untouched. The final
row bitmap is unchanged either way, since it is intersected with the condition
ranges afterwards.
The same block also intersected the condition ranges with the zone map
ranges twice and reported the (always empty) difference of the second,
idempotent intersection as `RowsZoneMapRuntimePredicateFiltered`. That counter
lost its source when the top-n filter became a regular pushed-down conjunct in
#59005, so this PR drops the duplicated intersection together with the counter
instead of keeping a profile row that can only ever be 0.
Note that this does not change how much work the zone map path does: the
per-column zone map evaluation still walks every page of the segment, so
`GenerateRowRangeByZoneMapIndexTime` stays the same. Limiting that walk would
need the candidate ranges to be pushed into
`ColumnIterator::get_row_ranges_by_zone_map()`, which is a larger interface
change and is left out here.
### Release note
None
### Check List (For Author)
- Test:
- Unit Test: Yes, `SegmentIteratorKeyRangeStatsTest` covers a point
lookup whose key range already selects a single row (no rows counted as
zone-map filtered) and the same predicate without a key range (zone map still
prunes pages).
- Regression test: Yes, `point_lookup_zone_map_profile` asserts the
counters in the profile of such a point lookup.
- Behavior changed: Yes, profile only. `RowsStatsFiltered` /
`RowsBloomFilterFiltered` no longer count rows that the key range or an index
already removed, and the `RowsZoneMapRuntimePredicateFiltered` counter is
removed.
- Does this need documentation: No
https://claude.ai/code/session_01RZ36Pij3o8fGnYYg33PKnq
--
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]
