Re: Locking in PostgreSQL?
От | Erik Jones |
---|---|
Тема | Re: Locking in PostgreSQL? |
Дата | |
Msg-id | 45770754.8030500@myemma.com обсуждение исходный текст |
Ответ на | Re: Locking in PostgreSQL? (Casey Duncan <casey@pandora.com>) |
Список | pgsql-performance |
Casey Duncan wrote: > On Dec 5, 2006, at 11:04 PM, Joost Kraaijeveld wrote: > >> Does PostgreSQL lock the entire row in a table if I update only 1 >> column? > > Know that updating 1 column is actually updating the whole row. So if > one transaction updates column A of a row, it will block another > concurrent transaction that tries to update column B of the same row. > As was mentioned however, neither of these transactions block others > reading the row in question, though they see the row as it existed > before the updates until those update transactions commit. > > If you know that your application will suffer excessive update > contention trying to update different columns of the same row, you > could consider splitting the columns into separate tables. This is an > optimization to favor write contention over read performance (since > you would likely need to join the tables when selecting) and I > wouldn't do it speculatively. I'd only do it if profiling the > application demonstrated significantly better performance with two > tables. > > -Casey Or, come up with some kind of (pre)caching strategy for your updates wherein you could then combine multiple updates to the same row into one update. -- erik jones <erik@myemma.com> software development emma(r)
В списке pgsql-performance по дате отправления: