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.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
