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
