Re: VACUUM and 24/7 database operation
От | Sanjay Arora |
---|---|
Тема | Re: VACUUM and 24/7 database operation |
Дата | |
Msg-id | 200101232004.BAA25046@tcs.com обсуждение исходный текст |
Ответ на | Re: VACUUM and 24/7 database operation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: VACUUM and 24/7 database operation
|
Список | pgsql-general |
Tom, Shouldn't it be possible to build vacuum as an ongoing internal PG process, instead of a seperate operation? How does Oracle byepass this? Must be some way that can be implemented. Any pointers to further reading to brush up my theory in this regard please? IAC, regarding the actual inquiry, wouldn't be a replicated database on a second server be more cheaper than Oracle, if the party is satisfied with PG performance? I browsed some PG commercial organization site that told about a Replication Server being available for PG. I am about to look into that next month. Is it any good like PG? Will provide failover too..rather than using Oracle. With best regards. Sanjay. At 05:53 PM 1/23/01 , Tom Lane wrote: >Thomas.Favier@accelance.fr writes: >> - Is 2 minutes a standard time for vacuuming a 500.000 rows table ? >> - Can it be reduced ? >> - In a far future, what are the problems we can run into not vacuuming >> that table ? We have already seen that after a month, some transactions >> involving where id >= some_value take forever, so we supressed them. > >If it takes a month before query performance gets bad, then perhaps you >could vacuum the table only once a month. However, that vacuum would >probably take longer than two minutes, so it's a tradeoff... > >We have plans for 7.2 to reduce the need for periodic vacuums, but that >won't help you much now. > >There are patches available for a "lazy vacuum" process on 7.0.3, >which can be a win if vacuum only needs to get rid of a few rows. >But they're not very thoroughly tested IMHO. See >http://people.freebsd.org/~alfred/vacfix/ > > regards, tom lane >
В списке pgsql-general по дате отправления: