Alvaro Herrera wrote:
> Matthew T. O'Connor wrote:
>
>> This still seems ambiguous to me, how would I handle a maintenance
>> window of Weekends from Friday at 8PM though Monday morning at 6AM? My
>> guess from what said is:
>> mon dom dow starttime endtime
>> null null 6 20:00 null
>> null null 1 null 06:00
>>
>> So how do we know to vacuum on Saturday or Sunday? I think clearly
>> defined intervals with explicit start and stop times is cleaner.
>>
>
> mon dom dow start end
> null null 5 20:00 23:59:59
> null null 6 00:00 23:59:59
> null null 7 00:00 23:59:59
> null null 1 00:00 06:00
>
> (1 = monday, 5 = friday)
>
So it takes 4 lines to handle one logical interval, I don't really like
that. I know that your concept of interval groups will help mask this
but still.
> Now I'm starting to wonder what will happen between 23:59:59 of day X
> and 00:00:00 of day (X+1) ... Maybe what we should do is not specify
> an end time, but a duration as an interval:
>
> month int
> dom int
> dow int
> start time
> duration interval
>
> That way you can specify the above as
> mon dom dow start duration
> null null 5 20:00 (4 hours + 2 days + 6 hours)
>
> Now, if a DST boundary happens to fall in that interval you'll be an
> hour short, or it'll last an hour too long :-)
>
I certainly like this better than the first proposal, but I still don't
see how it's better than a full set of columns for start and end
times. Can you tell me why you are trying to avoid that design?
>> Hmm... this seems like queue is nearly a synonym for group. Can't we
>> just add num_workers property to table groups? That seems to accomplish
>> the same thing. And yes, a GUC variable to limits the total number of
>> concurrent autovacuums is probably a good idea.
>>
>
> queue = group of groups. But I'm not sure about this at all, which is
> why I took it away from the proposal.
I think we can live without the groups of groups, at least for now.