From: | Tim Allen <tim(at)proximity(dot)com(dot)au> |
---|---|
To: | Alvaro Herrera <alvherre(at)surnet(dot)cl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Autovacuum in the backend |
Date: | 2005-06-17 01:04:33 |
Message-ID: | 42B221A1.8000200@proximity.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general 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(at)proximity(dot)com(dot)au
Proximity Pty Ltd http://www.proximity.com.au/
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-06-17 02:12:06 | Re: Autovacuum in the backend |
Previous Message | David Pratt | 2005-06-17 00:23:11 | Advice on structure /sequence / trigger |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-06-17 01:41:05 | Re: [PATCHES] Escape handling in strings |
Previous Message | Andrew Dunstan | 2005-06-17 01:03:04 | Re: [PATCHES] Escape handling in strings |