Re: Autovacuum improvements
От | Matthew T. O'Connor |
---|---|
Тема | Re: Autovacuum improvements |
Дата | |
Msg-id | 45AD1D51.1060003@zeut.net обсуждение исходный текст |
Ответ на | Re: Autovacuum improvements (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: