Re: Autovacuum improvements

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.