| От | Jim C. Nasby |
|---|---|
| Тема | Re: SELECT FOR UPDATE performance is bad |
| Дата | |
| Msg-id | 20060420165002.GY49405@pervasive.com обсуждение исходный текст |
| Ответ на | Re: SELECT FOR UPDATE performance is bad (Mario Splivalo <mario.splivalo@mobart.hr>) |
| Список | pgsql-performance |
On Wed, Apr 19, 2006 at 10:20:54AM +0200, Mario Splivalo wrote: > This works perfectly, but sometimes the game has no codes, and I still > need to know exactley who came first, who was second, and so on... So a > locking table as Tom suggested is, I guess, a perfect solution for my > situation... Depending on your performance requirements, you should look at contrib/userlock as well, since it will probably be much more performant than locking a row in a table. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера