morningman opened a new pull request, #69583:
URL: https://github.com/apache/doris/pull/69583
### What problem does this PR solve?
Issue Number: None
Related PR: #67005
Problem Summary:
**In short.** This ports the profile fix that branch-4.1/4.2 made in #67005
to master: the second phase of TopN lazy materialization on external tables
reported a wrong `InitReaderAvgTime` and put the init time into
`GetBlockAvgTime`. It also stops one request block's averages from leaking into
the next one of the same RPC, which the 4.x fix still does.
Original author: @zhangstar333
**Background.** When a TopN query lazily materializes an external table, the
second phase sends the row IDs to the backends that own the rows. On each
backend, `RowIdStorageReader::read_batch_external_row` reads one request block
(one table) by grouping its row IDs per scan range and reading each range with
its own reader. It then reports two values per request block:
`InitReaderAvgTime` and `GetBlockAvgTime`, the mean reader-init and block-read
time over those ranges. `MaterializationOperator` lists them per backend in the
query profile, one value per RPC response block.
**The problem, and what it cost.** Both values are wrong on master:
- `InitReaderAvgTime` assigns each range's init time instead of adding it,
so it is the last range's init time divided by the number of ranges.
- `GetBlockAvgTime` is filled with the init-time average, so the block-read
time never reaches the profile.
- The averages are accumulated in variables that `read_by_rowids()` zeroes
once per RPC and passes to every request block. A query that lazily
materializes two external tables sends two request blocks in one RPC, and the
second block's sums start from the first block's averages.
So the profile of a slow lazily materialized external read cannot tell
whether opening the readers or reading the rows took the time. Only the profile
and one log line are affected; the fetched rows are not. #67005 (a Lance
profile PR in 4.x) fixed the first two points; branch-4.1 and branch-4.2 still
have the third.
**How this PR fixes it.** The summary moves into
`RowIdStorageReader::add_external_fetch_avg_time_profile()`. It sums both times
over the block's ranges starting from zero, overwrites the caller's variables
with the averages, and reports each average under its own key. The `Query
stats` log line at the end of `read_by_rowids()` prints those variables, so it
now shows the averages of the RPC's last external request block, the same block
whose scan range count it already prints.
**Results.** `InitReaderAvgTime / GetBlockAvgTime` for a request block with
three ranges that took 10/100, 20/200 and 60/600 ms (init/read), first as the
only external block of the RPC, then as the second one after a block that left
50/500 ms in the shared variables:
| | Only request block | Second request block |
|---|---|---|
| master | 20ms / 20ms | 20ms / 20ms |
| branch-4.1/4.2 after #67005 | 30ms / 300ms | 46ms / 466ms |
| This PR | 30ms / 300ms | 30ms / 300ms |
### Release note
None
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [ ] Regression test
- [x] Unit Test
-
`RowIdStorageReaderTest.ExternalFetchProfileAveragesInitAndGetBlockTimes`: the
three ranges above, with the caller's variables preset to 50/500 ms as a
previous request block would leave them, give 30ms and 300ms. It fails with
master's assignment (20ms), with `GetBlockAvgTime` reporting the init average
(30ms), and with the 4.x accumulation (46ms / 466ms). The other
`RowIdStorageReaderTest` and `SubmitExternalScanTasksTest` cases still pass.
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- Behavior changed:
- [x] No.
- [ ] Yes. <!-- Explain the behavior change -->
- Does this need documentation?
- [x] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/1214 -->
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR should
merge into -->
--
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]
