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)

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 had two ideas: one was to make pg_autovacuum hold default config for
> >all tables not mentioned in any group, so sites which are OK with 8.2's
> >representation can still use it.  The other idea was to remove it and
> >replace it with this mechanism.
> Probably best to just get rid of it.  GUC variables hold the defaults 
> and if we create a default interval / group, it will also have defaults.

Yeah, maybe.

> >My idea was to assign each table, or maybe each group, to a queue, and
> >then have as much workers as there are queues.  So you could put them
> >all in a single queue and it would mean there can be at most one vacuum
> >running at any time.  Or you could put each group in a queue, and then
> >there could be as many workers as there are groups.  Or you could mix.
> >
> >And also there would be a "autovac concurrency limit", which would be
> >a GUC var saying how many vacuums to have at any time.
> 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.

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to