gitccl opened a new pull request, #18364: URL: https://github.com/apache/doris/pull/18364
# Proposed changes Issue Number: close #xxx ## Problem summary #18015 enables stream load profile log. When `is_report_success` is true, be will reportExecStatus to fe, but fe cannot find QueryInfo in `coordinatorMap`, thus it will return error to be. https://github.com/apache/doris/blob/a724443eb92a84a2c0167033cf08ec95b1369d96/fe/fe-core/src/main/java/org/apache/doris/qe/QeProcessorImpl.java#L181-L195 To solve this problem, we first add a filed named `query_type` to `TReportExecStatusParams` to distinguish whether the query is `SELECT` or `LOAD`. If fe cannot find QueryInfo in `coordinatorMap` and the `query_type` is `LOAD`, it means this query is stream load, and we can return OK. And in #18015 , it's not a good idea to use a globle BE config `enable_stream_load_profile_log` to control whether print profile to log. Thus we add a new param `enable_profile` to stream load to control whether each stream load job prints profile to log. I tested loading tpch data, it can be loaded without error. When `enable_profile` is true, stream load profile is printed to the log: ``` I0404 10:12:21.240705 2336167 plan_fragment_executor.cpp:523] Fragment c54fa880c606e9ae-b43f30b6927103a6:(Active: 1m2s, non-child: 0.04%) - BlocksProduced: 12.00M - FragmentCpuTime: 4s384ms - RowsProduced: 12.00M OlapTableSink:(Active: 1m2s, non-child: 99.01%) - CloseWaitTime: 5s166ms - MaxAddBatchExecTime: 56s833ms - NonBlockingSendTime: 59s837ms - NonBlockingSendWorkTime: 4s884ms - SerializeBatchTime: 4s028ms - NumberBatchAdded: 985 - NumberNodeChannels: 1 - OpenTime: 787.612us - RowsFiltered: 0 - RowsRead: 12.00M - RowsReturned: 12.00M - SendDataTime: 56s611ms - WaitMemLimitTime: 52s676ms - TotalAddBatchExecTime: 56s833ms - ValidateDataTime: 355.313ms VFILE_SCAN_NODE (id=0):(Active: 596.764ms, non-child: 0.95%) - UseSpecificThreadToken: False - AcuireRuntimeFilterTime: 462.000ns - BytesDecompressed: 0 - BytesRead: 1.45 GB - DecompressTime: 0.000ns - FileReadTime: 496.605ms - GetNextTime: 595.397ms - MaxScannerThreadNum: 1 - NumScanners: 1 - PeakMemoryUsage: 0 - PreAllocFreeBlocksNum: 8 - ProjectionTime: 0.000ns - RowsRead: 12.00M - RowsReturned: 12.00M - RowsReturnedRate: 20.11 M/sec - ScannerWorkerWaitTime: 21.051ms - TotalReadThroughput: 0 VScanner: - PerScannerRunningTime: [13s612ms, ] - PerScannerRowsRead: [12.00M, ] - EmptyFileNum: 0 - FileScannerCastInputBlockTime: 291.989ms - FileScannerConvertOuputBlockTime: 4s568ms - FileScannerFillMissingColumnTime: 0.000ns - FileScannerFillPathColumnTime: 0.000ns - FileScannerGetBlockTime: 8s700ms - FileScannerPreFilterTimer: 0.000ns - NewlyCreateFreeBlocksNum: 88 - ScannerBatchWaitTime: 572.725ms - ScannerConvertBlockTime: 0.000ns - ScannerCpuTime: 13s542ms - ScannerCtxSchedCount: 741 - ScannerFilterTime: 420.815us - ScannerGetBlockTime: 13s609ms - ScannerPrefilterTime: 0.000ns - ScannerSchedCount: 648 MemoryUsage: - FreeBlocks: 53.25 MB - QueuedBlocks: 53.25 MB MemoryUsage: - FreeBlocks: 53.25 MB - QueuedBlocks: 53.25 MB ``` ## Checklist(Required) * [ ] Does it affect the original behavior * [ ] Has unit tests been added * [X] Has document been added or modified * [ ] Does it need to update dependencies * [X] Is this PR support rollback (If NO, please explain WHY) ## Further comments If this is a relatively large or complex change, kick off the discussion at [[email protected]](mailto:[email protected]) by explaining why you chose the solution you did and what alternatives you considered, etc... -- 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]
