Details
-
Brainstorming
-
Status: Closed
-
Critical
-
Resolution: Abandoned
-
0.99.0
-
None
-
None
Description
It's a little bit of a provocation, but the rational is:
- there are some bugs around the delayed flush. For example, if the periodic scheduler has asked for a delayed flush, and that we need to flush, we will have to wait
- if the number of WAL files increases, we won't flush immediately if the blockingFile number has been reached. This impacts the MTTR.
- We don't write to limit the compaction impact, but they are many cases where we would want to flush anyway, as the writes cannot wait.
- this obviously leads to huge write latency peaks.
So I'm questioning this setting, it leads to multiple intricate cases, unpredictable write latency, and looks like a workaround for compaction performances. With all the work done on compaction, I think we can get rid of it. A solution in the middle would be to deprecate it and to set it to a large value...
Any opinion before I shoot ?