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 по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Reducing relation locking overhead
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCHES] Inherited Constraints