Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)
Дата
Msg-id 87pso9iw69.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing  (Hannu Krosing <hannu@skype.net>)
Ответы Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing  (Hannu Krosing <hannu@skype.net>)
Список pgsql-hackers
Hannu Krosing <hannu@skype.net> writes:

> The scenario where concurrent create index command is be needed is 24/7
> OLTP databases, which can't be taken down for maintenance. Usully they
> can be arranged to tolerate postponing a few transactions for one
> second.

Well, the dominant defining characteristic of "OLTP" is precisely that you do
*not* have under your control the timing requirements and can't make such
arrangements. That is, you have to process requests as fast as they come in
whatever that might be.

But that said, realistically *any* solution has to obtain a lock at some time
to make the schema change. I would say pretty much any O(1) (constant time)
outage is at least somewhat acceptable as contrasted with the normal index
build which locks out other writers for at least O(n lg n) time. Anything on
the order of 100ms is probably as good as it gets here.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] 8.1, OID's and plpgsql
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: Oddity with extract microseconds?