Re: Management of Concurrent Clients
От | Tino Wildenhain |
---|---|
Тема | Re: Management of Concurrent Clients |
Дата | |
Msg-id | 440201D8.4090009@wildenhain.de обсуждение исходный текст |
Ответ на | Re: Management of Concurrent Clients ("Hanan Bentaleb" <Hanan.Bentaleb@simplernetworks.com>) |
Ответы |
Re: Management of Concurrent Clients
|
Список | pgsql-general |
Hanan Bentaleb schrieb: > Hi Tino, > > Thanks for your response! I did not provide more specific technical > details because I just came in to the project. So, I will try to provide > as much information as I can. > > Former versions of postgresql used in this project are postgresql > (starting at 6). I will try to find out the exact revision number. > > It has been reported to me that the main problem encountered with former > postgresql versions is that when a process performs an update (of a > record in any table), the whole database was locked which prevents the > other processes from accessing the database (to retrieve data for > instance). In other words, the process performing the update operation > had an exclusive access to the database. This had an important impact on > the system performance and justified the fact that tables were spread > into different databases. > > Usually, granularity on locks is at the row or table level but maybe > there was a specific configuration that was used which made it so that > the entire database was locked. Before starting any major database > re-structuring, I want to make sure that are not specific cases where > this situation occurs. I wonder how they managed to lock the whole database. You can try and lock a table but usually its virtually unlocked (thanks to MVCC). And even 6.x had MVCC. You schould give us an example what they do. Otherwise it sounds like a myth :) Regards Tino
В списке pgsql-general по дате отправления: