Re: Locking in PostgreSQL?
От | Dave Cramer |
---|---|
Тема | Re: Locking in PostgreSQL? |
Дата | |
Msg-id | 4ED560E4-3484-43BA-99BB-18888D968F74@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: Locking in PostgreSQL? ("Jens Schipkowski" <jens.schipkowski@apus.co.at>) |
Ответы |
Re: Locking in PostgreSQL?
Re: [GENERAL] Locking in PostgreSQL? Re: [GENERAL] Locking in PostgreSQL? |
Список | pgsql-performance |
On 6-Dec-06, at 8:20 AM, Jens Schipkowski wrote: > On Wed, 06 Dec 2006 13:29:37 +0100, Dave Cramer <pg@fastcrypt.com> > wrote: > >> Unless you specifically ask for it postgresql doesn't lock any >> rows when you update data. >> > Thats not right. UPDATE will force a RowExclusiveLock to rows > matching the WHERE clause, or all if no one is specified. > @Joost Kraaijeveld: Yes, because there is no EntryExclusiveLock or > something like that. Roughly you can say, each UPDATE statement > iterates through the affected table and locks the WHERE clause > matching records (rows) exclusivly to prevent data inconsistancy > during the UPDATE. After that your rows will be updated and the > lock will be repealed. > You can see this during an long lasting UPDATE by querying the > pg_locks with joined pg_stats_activity (statement must be enabled). Apparently I've completely misunderstood MVCC then.... My understanding is that unless you do a select ... for update then update the rows will not be locked . Dave > >> Dave >> On 6-Dec-06, at 2:04 AM, Joost Kraaijeveld wrote: >> >>> Does PostgreSQL lock the entire row in a table if I update only 1 >>> column? >>> >>> >>> --Groeten, >>> >>> Joost Kraaijeveld >>> Askesis B.V. >>> Molukkenstraat 14 >>> 6524NB Nijmegen >>> tel: 024-3888063 / 06-51855277 >>> fax: 024-3608416 >>> web: www.askesis.nl >>> >>> ---------------------------(end of >>> broadcast)--------------------------- >>> TIP 9: In versions below 8.0, the planner will ignore your desire to >>> choose an index scan if your joining column's datatypes do >>> not >>> match >>> >> >> >> ---------------------------(end of >> broadcast)--------------------------- >> TIP 9: In versions below 8.0, the planner will ignore your desire to >> choose an index scan if your joining column's datatypes do not >> match > > > > CU, > Jens > > -- > ** > Jens Schipkowski > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
В списке pgsql-performance по дате отправления: