Thread: FW: Postgres: VACUUM
> On heavily used databases (over 100,000 transactions an > hour), vacuum is > a killer That's about 27 tx/second - not so many, for some tasks at least. If VACUUM is rather a killer - are any plans from PostgreSQL to deal with that? Thank you in advance, Laimis P.S. it's notable that every DB system I delt with had one or another issue as far as concurency is concerned, take infamous "Oracle-1555 snapshot too old" error as an example.
On Wed, 14 Jan 2004 lnd@hnit.is wrote: > > > On heavily used databases (over 100,000 transactions an > > hour), vacuum is > > a killer > > That's about 27 tx/second - not so many, for some tasks at least. > > If VACUUM is rather a killer > - are any plans from PostgreSQL to deal with that? Yes, Tom and friends have been tossing back and forth a patch to implement a sleep between x number of pages being vacuumed to remove the heavy load vacuum can place on a system. Early testing looks promising, so it's likely that if enough of us order Tom or somebody a pizza it will get done. :-) I certainly would like to see it.
lnd@hnit.is writes: >> On heavily used databases (over 100,000 transactions an hour), >> vacuum is a killer > > That's about 27 tx/second - not so many, for some tasks at least. > > If VACUUM is rather a killer > - are any plans from PostgreSQL to deal with that? Yes. There is a patch available that causes VACUUM to sleep() after every few pages it processes, which throttles VACUUM's ill effects on cache. It isn't yet in 7.4.1, but might be in a later 7.4 release. There is also a major revision taking place (look up "ARC" on the hackers list) for management of cache that should also be helpful. -- let name="cbbrowne" and tld="libertyrms.info" in String.concat "@" [name;tld];; <http://dev6.int.libertyrms.com/> Christopher Browne (416) 646 3304 x124 (land)