Re: Feature freeze date for 8.1

I think what you're suggesting is that vacuum settings (most likely
delay) take into consideration the load on the database, which I think
is a great idea. One possibility is if vacuum tracks how many blocks
it's read/written, it can see how many blocks the database has done
overall; subtract the two and you know how much other disk IO is going
on in the system. You can then use that number to decide how long you'll
sleep before the next vacuum cycle.

On Fri, Apr 29, 2005 at 01:34:56PM -0300, Marc G. Fournier wrote:
> On Fri, 29 Apr 2005, Tom Lane wrote:
>
> >"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> >>What to people think about having an optional "maintenance window" so
> >>that autovac only takes action during an approved time. But perhaps
> >>just using the vacuum delay settings will be enough.
> >
> >I'm not sure autovac should go completely catatonic during the day;
> >what if someone does an unusual mass deletion, or something? But
> >it does seem pretty reasonable to have a notion of a maintenance
> >window where it should be more active than it is at other times.
> >
> >Maybe what you want is two complete sets of autovac parameters.
> >Definitely at least two sets of the vacuum-delay values.
>
> With the introduction of the stats collector, is there not some way of
> extending it so that autovac has more information to work off of? For
> instance, in my environment, we have clients in every timezone hitting the
> database ... our Japanese clients will be busy at a totally different time
> of day then our East Coast/NA clients, so a 'maintenance window' is near
> impossible to state ...
>
> I know one person was talking about being able to target only those that
> pages that have changes, instead of the whole table ... but some sort of
> "load monitoring" that checks # of active connections and tries to find
> 'lulls'?
>
> Basically, everything right now is being keyed to updates to the tables
> themselves, but isn't looking at what the system itself is doing ... if
> I'm doing a massive import of data into a table, the last time I want is a
> VACUUM to cut in and slow down the loading ...
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"