Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing
От | Csaba Nagy |
---|---|
Тема | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing |
Дата | |
Msg-id | 1134036317.4779.246.camel@coppola.muc.ecircle.de обсуждение исходный текст |
Ответ на | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
On Wed, 2005-12-07 at 19:36, Greg Stark wrote: [snip] > We periodically ran into problems with load spikes or other performance > problems causing things to get very slow and stay slow for a while. Letting > things settle out usually worked but occasionally we had to restart the whole > system to clear out the queue of requests. Just as a personal opinion: I would love a REINDEX which does not block reads/writes, even if writes will be more expensive while it's running. There's always a period of time I can schedule the REINDEX so there's very low write activity, but it is impossible to find a time slot when there's NO write activity... and I think most of the real world applications are like this. I think it's very rare that an application is constantly getting high load, but most of them are constantly getting SOME important activity which makes downtime hard to schedule. Now if the slowdown of writes is not more than the acceptable service level, then it is a very workable solution to schedule the REINDEX on a not so busy time slot. Cheers, Csaba.
В списке pgsql-hackers по дате отправления: