> >uh...isn't that what cron is for????
>
> Sure. If:
>
> A. The person who creates the database is allowed to add cron jobs.
> [A host ISP could easily and quite reasonably make this not be true.]
Well, if they have the authority to create the database but not to use cron,
then its the sysadmin job. If the sysadmin won't do it, the organization has
problem postgres can't fix (some problems arn't computer problems).
> B. You know that you need to run vacuum regularly.
That is a documentation issue.
> C. You know that cron runs regularly for tasks like this.
That is another documentation issue. When I worked for BLAST we actually had a
tech note for using our product out of cron. If a FAQ does not exist for this,
or its not in the documentation, that would be a good one to have. You don't
have to explain cron completely, you just need to show some basic examples of
saying kicking off a vacuum from cron, and of course point them to cron's man
page for the gory details.
> D. The webmaster who creates the db knows enough Unix to add cron jobs.
> [See *long* section below:]
Another documentation issue.
>
>
> For most folks creating databases, all of the above is probably true. But,
> as PostgreSQL becomes more popular, and with the explosion of virtual
> hosting, you're going to see a whole lot of users who will fail at least
> one of the above. Do you really want to keep answering this vacuum/cron
> question every week?
Again, a documentation issue, though I am not opposed to automatic vacuums, as
long as they are tunable, but it is pretty much standard operating procedures
under UNIX to use cron to automate things like this.
> Why should every PostgreSQL user have to set this up for every editable
> database? Isn't it an axiom to set things up for the most common
> situtation, with over-rides for the uncommon, unless there are significant
> performance penalties or other, similar, more important reasons not to do
> so?
A good point...james
