No one would expect Oracle to install Oracle and walk away. We are not
MySQL, nor MS Access.
I can definitely see where you're coming from, it's a sort of tough-love
scenario. There are legitimate counter arguments, though. The most
obvious is that anyone who *does* evaluate their needs properly
shouldn't have too much trouble turning it off, whereas there are lots
of small database users out there who find having to set up a vacuum
cron a pain. Example: I'm in the process of setting up a typo blog,
using postgresql of course, but the database setup was secondary to the
main thing that I was doing, and I'd completely forgotten about setting
up a cron. Now I'm unlikely to produce blog posts at a rate that will
cause the database to grow out of the "minuscule" range, but it should
still be done, right?
I have to ask, what's wrong with lazy users? Software which allows you
to be lazy gives you a warm tingly feeling, and you install it on your
intranet server when no-one's looking. We want people to think of
postgresql that way.
There are lots of MySQL specific pieces of software out there that
started out as some guy/girl with a PHP and MySQL type of book. We can't
turn that clock back, but making postgresql easier for the masses has to
be a good thing for its adoption. The native win32 port is the poster
child for this. It was a big PR win, no?
I would argue that leaving autovacuum off is only justifiable if we feel
that it's going to be a bad choice for the majority of users. Many of
the users who frequent postgresql lists understand the trade-off, but
the ones that we're trying to attract don't. Is it better for them to
discover manual vacuums when they're trying to incrementally improve
performance (with the risk that they never discover them at all), or
when their database is running like a dog because they've never vacuumed
it at all?
One solution might be to turn it on in turn-key solutions: linux distro
RPMs, Win32 installer (is it on there already?) etc, but leave it turned
off in the source release. Would that help you, or are your clients
using RPMs or whatever?
Cheers
Tom
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
