Re: Catching up Production from Warm Standby aftermaintenance - Please help
От | Alvaro Herrera |
---|---|
Тема | Re: Catching up Production from Warm Standby aftermaintenance - Please help |
Дата | |
Msg-id | 20090707173041.GI7694@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Catching up Production from Warm Standby aftermaintenance - Please help ("Scott Whitney" <swhitney@journyx.com>) |
Ответы |
Re: Catching up Production from Warm Standbyaftermaintenance - Please help
|
Список | pgsql-admin |
Scott Whitney escribió: > I'd like to phone in with a slightly different opinion on VACUUM FULL. Yeah, > it should be avoided when possible, but it's not always possible. In our > case, I've got 300ish databases backing to a single database server. Each of > those dbs has a couple of hundred tables and a hundred or more views. The > product (Journyx Timesheet) is pretty complex, and I find that if I do _not_ > perform a full vacuum once per week, my customer dbs start to slow down > inordinately. Queries which would run in 1-2 seconds will run in 30-40 > seconds after a few weeks of not performing a full vacuum. I've got autovac > running on all dbs. That's most likely because you have too small an FSM. Have you tuned that? > Now, that could well be due to index bloat with complex indexes, VACUUM FULL does not clean indexes. > or it could be due to a variety of other factors, but also my pg_clog > directory does not clear out, but continues to create new clog > segments. That's expected. If pg_clog size bothers you, there's another parameter you can tweak. However, pg_clog size should not normally be a problem; it's just 32kB for every million transactions or something like that. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-admin по дате отправления: