Re: Autovacuum in the backend - Mailing list pgsql-hackers

From Tim Allen
Subject Re: Autovacuum in the backend
Date
Msg-id 42B221A1.8000200@proximity.com.au
Whole thread Raw
In response to Re: Autovacuum in the backend  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus wrote:
> Alvaro,
> 
> 
>>coffee-with-cream vacuums.
> 
> I tried this and now my Hoover makes this horrible noise and smokes.  ;-)

Probably related to the quality of American coffee ;).

> All:
> 
> Seriously, all:  when I said that "users" were asking for Autovac in the 
> backend (AVitB), I wasn't talking just the newbies on #postgresql.   I'm also 
> talking companies like Hyperic, and whole groups like the postgresql.org.br.   
> This is a feature that people want, and unless there's something 
> fundamentally unstable about it, it seems really stupid to hold it back 
> because we're planning VACUUM improvements for 8.2.
> 
> AVitB has been on the TODO list for 2 versions.   There's been 2 years to 
> question its position there.   Now people are bringing up objections when 
> there's no time for discussion left?  This stinks.

Complete agreement from me. Incremental improvements are good - pointing 
out that there are some other incremental improvements that would also 
be good to make is not an argument for delaying the first set of 
incremental improvements.

In our case, we want to be able to install postgres at dozens (ideally 
hundreds... no, thousands :) ) of customer sites, where the customers in 
general are not going to have anyone onsite who has a clue about 
postgres. The existing contrib autovacuum gives a good solution to 
setting things up to maintain the database in a reasonable state of 
health without need for further intervention from us. It's not perfect, 
of course, but if it means the difference between having to unleash our 
support team on a customer once a month and once a year, that's a good 
deal for us. Having it integrated into the backend will make it much 
easier for us, we (hopefully...) won't have to fiddle with extra startup 
scripts, and we'll have one fewer point of failure (eg some customer 
might accidentally turn off the separate pg_autovacuum daemon). Being 
able to customise the autovacuum parameters on a per-table basis is also 
attractive.

Just my AUD0.02. I realise that keeping _our_ customers happy is not 
necessarily anyone else's priority. I'd like to be able to invest some 
coding time, but can't. I haven't even gotten around to completing 
Gavin's survey form (sorry Gav, I'll get to it soon, I hope! :)), so I 
can't demand to be listened to.

But for what it's worth, Alvaro, please keep going, don't be dissuaded.

Tim

-- 
-----------------------------------------------
Tim Allen          tim@proximity.com.au
Proximity Pty Ltd  http://www.proximity.com.au/


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: DTrace Probes?
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Escape handling in strings