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

Reply via email to