Skip site navigation (1) Skip section navigation (2)

Re: Feature freeze date for 8.1

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>,Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Feature freeze date for 8.1
Date: 2005-04-29 16:34:56
Message-ID: 20050429132209.D53065@ganymede.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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

In response to

Responses

pgsql-hackers by date

Next:From: Michael FuhrDate: 2005-04-29 17:21:35
Subject: Re: [GENERAL] Returning a RECORD, not SETOF RECORD
Previous:From: Bruno Wolff IIIDate: 2005-04-29 16:10:11
Subject: Re: Feature freeze date for 8.1

pgsql-patches by date

Next:From: Christopher BrowneDate: 2005-04-29 22:15:18
Subject: Re: Feature freeze date for 8.1
Previous:From: Bruno Wolff IIIDate: 2005-04-29 16:10:11
Subject: Re: Feature freeze date for 8.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group