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?




   === 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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to