[
https://issues.apache.org/jira/browse/KUDU-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17633469#comment-17633469
]
dengke commented on KUDU-3367:
------------------------------
Yes. It didn't happen again for a long time after this happened before, until
last week. I tried to set `tablet_history_max_age_sec` to a small value
according to what [~zhangyifan27] said. After observing for a while, I found
that it had no effect.
The code implementation of KUDU-1625 is based on 'live row count', but I found
that this version is too old to support this feature in the environment with
problems：
!image-2022-11-14-11-02-33-685.png!
So I think it is necessary to develop new processing methods for the data of
the old version Kudu.
> Delta file with full of delete op can not be schedule to compact
> ----------------------------------------------------------------
>
> Key: KUDU-3367
> URL: https://issues.apache.org/jira/browse/KUDU-3367
> Project: Kudu
> Issue Type: New Feature
> Components: compaction
> Reporter: dengke
> Assignee: dengke
> Priority: Major
> Attachments: image-2022-05-09-14-13-16-525.png,
> image-2022-05-09-14-16-31-828.png, image-2022-05-09-14-18-05-647.png,
> image-2022-05-09-14-19-56-933.png, image-2022-05-09-14-21-47-374.png,
> image-2022-05-09-14-23-43-973.png, image-2022-05-09-14-26-45-313.png,
> image-2022-05-09-14-32-51-573.png, image-2022-11-14-11-02-33-685.png
>
>
> If we get a REDO delta with full of delete op, wich means there is no update
> op in the file. The current compact algorithm will not schedule the file do
> compact. If such files exist, after accumulating for a period of time, it
> will greatly affect our scan speed. However, processing such files every time
> compact reduces compact's performance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
