Plan sounds reasonable to me also.
> On 6 Sep 2019, at 15:15, Paul Davis <paul.joseph.da...@gmail.com> wrote:
>
> Seems mostly reasonable. The only thing I'd add is that if we're
> looking to implement #1 I'd assume we'd reuse or at least rework the
> old compaction daemon code which makes me think that #3 would be
> trivial to support?
>
> On Fri, Sep 6, 2019 at 8:25 AM Adam Kocoloski <kocol...@apache.org> wrote:
>>
>> Hi all,
>>
>> CouchDB 3.0 will feature a new, smarter auto-compaction daemon with the
>> following key features:
>>
>> - continuous re-prioritization of compaction queues based on estimated space
>> savings
>> - fine-grained control over compaction “channels” to independently
>> prioritize different types of jobs (large databases, small views, etc.)
>> - QoS capabilities: compaction I/O is executed at low priority by default,
>> but admins can can reprioritize as needed
>>
>> However, there are a few gaps compared to the daemon in 2.x:
>>
>> 1. no ability to configure compaction to only run during specific time
>> intervals
>> 2. no ability to specify compaction thresholds for specific databases
>> 3. incompatible configuration system; users who have customized their
>> auto-compaction configuration in 2.x will need to redo their configuration
>> in 3.0
>>
>> I have those gaps ordered in what I’d consider to be the priority. I think
>> we should try to address #1 before 3.0 as I’m sure many DBAs have grown
>> accustomed to compacting during quiet hours and could be forgiven if they
>> don’t trust our fancy QoS to keep things healthy on Day 1. I can see where
>> #2 could be a nice enhancement but I’m OK to wait for user feedback on that
>> one. #3 I’m content to solve with a migration guide in the documentation.
>>
>> Does that plan make sense to everyone?
>>
>> Adam
