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.
