Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing
| От | Hannu Krosing |
|---|---|
| Тема | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing |
| Дата | |
| Msg-id | 1133903265.3719.37.camel@localhost.localdomain обсуждение исходный текст |
| Ответ на | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Ühel kenal päeval, T, 2005-12-06 kell 16:01, kirjutas Tom Lane: > Hannu Krosing <hannu@skype.net> writes: > > 1) run a transaction repeatedly, trying to hit a point of no concurrent > > transactions, > > In the sort of 24x7 environment that people are arguing this is needed > for, it's entirely possible that that will *never* succeed. My OLTP transactions are usually 5-50ms in length. common sense tells me, that if I disallow new transactions for 100ms, I am more than likely to have waited for all existing ones to have finished and can do my 1 ms of "take snapshot + commit" and let all the waiting transactions to commence. If the database is running longer transactions, there can be a GUC to adjust the time CUNCURRENT CREATE INDEX will wait. For example for trx'es mostly in 0.5-2 sec range the wait could be set to 3 sec. ------------- Hannu
В списке pgsql-hackers по дате отправления: