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