From: Christopher Browne <cbbrowne@acm.org>
Subject: Re: [HACKERS] What can we learn from MySQL?
Date: Fri, 23 Apr 2004 14:18:14 -0400
Organization: cbbrowne Computing Inc
Lines: 46
Message-ID: <m365bqa789.fsf@wolfe.cbbrowne.com>
References: <20040423124716.521420c2.darcy@druid.net>
	<200404231708.i3NH8UM19188@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
 Obscurity,
	linux)
Cancel-Lock: sha1:Nf7KmBL1ZwAmpCMNlE/a+rsgS5I=
To: pgsql-advocacy@postgresql.org

Martha Stewart called it a Good Thing when pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> D'Arcy J.M. Cain wrote:
>> On Fri, 23 Apr 2004 11:07:20 -0400
>> Dave Cramer <pg@fastcrypt.com> wrote:
>> > Does the current implementation of pg_autovacuum have a way of setting
>> > windows where it is allowed to vacuum? Many large 24/7 will only allow
>> > vacuumming at certain times of the day.
>> 
>> It seems to me that the point of pg_autovacuum would be to run 24/7 so
>> that there is never big hit on the system.  Perhaps it could be designed
>> to throttle itself based on current system usage though.
>
> Or the number of connected backends, or both?

This is what suggests to me the possibility that perhaps a good
answer would be to redo it in some scripting language, and have the
capability to either:
 a) Configure multiple targets via some language-specific approach
    (e.g. - reading Perl data structures, or some such thing) or
 b) Configure multiple targets via having the configuration stored
    in one database/schema.

I would somewhat favor the latter.

The initial design was set up jointly with a view to 
 a) minimizing the number of extra dependancies, and
 b) ultimately being a stop-gap measure until a _proper_ scheme
    could get integrated into the postmaster.

The existing implementation has remained sufficiently fragile that we
have a hard time trusting it with the _important_ systems, and since
those systems tend to involve multiple backends, it sure would be nice
to have something that could get run across ALL of them, where we
could be confident that it wouldn't demolish I/O at inconvenient times
by trying to simultaneously vacuum huge tables on multiple backends.

I have lately been working on some (not quite yet sufficiently
generic) tools for managing sets of replication instances; I think I
may want to take a similar "tack" on this.  pg_autovacuum has been
handy for systems that I _don't_ want to pay much attention to, but it
hasn't been totally adequate for the more vital ones.
-- 
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/linuxdistributions.html
A real  patriot is the fellow  who gets a parking  ticket and rejoices
that the system works.