Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing
От | Hannu Krosing |
---|---|
Тема | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing |
Дата | |
Msg-id | 1133901931.3719.22.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)
|
Список | pgsql-hackers |
Ühel kenal päeval, T, 2005-12-06 kell 15:38, kirjutas Tom Lane: > Hannu Krosing <hannu@skype.net> writes: > > What I have in mind would be something like this to get both SNAP2 and > > commit between any transactions: > > > LOOP: > > LOCK AGAINST STARTING NEW TRANSACTIONS > > I can hardly credit that "let's block startup of ALL new transactions" > is a more desirable restriction than "let's block writers to the table > we wish to reindex". If the block is short-time (will be removed one way or other in a few (tenths of) seconds, then this is much more desirable than blocking writers for a few hours. 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. ---------- Hannu
В списке pgsql-hackers по дате отправления: