Russell Smith wrote:
* Reduces the total amount of time the system spends vacuuming since it
only vacuums when needed.
Can be easily done with cron.
Can you do partial table vacuums with CRON?
You can work out the smartest time to vacuum with cron? I thought it just
scheduled tasks at certain times.
To be fair, autovacuum can't do partial table vacuums either, in fact
nothing can right now. Perhaps someday something like this will be
feasible.
* Eliminates one of the criticisms that the public has against
PostgreSQL (justifed or not)
Agreed.
This is really the same as the previous RTFM question/response. People
criticise because vacuum is foreign to them,
and for newbie's that equals too hard, next db please. As much as it is a
technical issue, it's an advocacy issue too.
This bullet point is absolutely an advocacy issue. Every developer that
says "next db please" will probably not come back to PostgreSQL for
quite some time, thus bolstering the userbase of the competition and
reducing the userbase of PostgreSQL.
Plus we finally get XID wraparound protection. We finally decided that for 8.1
we needed some protection, which I think
Tom committed. This again may be a newbie thing. But there are a lot of
newbies out there then. We've see on the lists
and on IRC this problem pop up a number of times. And people say "Why didn't it
tell me", RTFM it's exactly what they want
to hear, or the fact they thought they read the manual, and missed
understanding that bit.
I think this point hasn't been stressed enough. With nested
transactions these days (not to mention faster hardware) I can see XID
wraparound becoming a much bigger issue.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
