Oh duh. I was only thinking about the scheduling aspect but I'm
guessing you were also thinking about the fragmentation settings and
so on that don't have a direct equivalent. Seems fair to me.

To be fair, that was before I was properly caffeinated.

On Fri, Sep 6, 2019 at 9:56 AM Adam Kocoloski <kocol...@apache.org> wrote:
>
> I was just going to port over the `check_period` function and add support for 
> “from” and “to” as per-channel config parameters, so I don’t think it will 
> meaningfully help with the rationalization of the config systems.
>
> Adam
>
> > On Sep 6, 2019, at 10:15 AM, 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
>

Reply via email to