Re: Update on true serializable techniques in MVCC
От | Nicolas Barbier |
---|---|
Тема | Re: Update on true serializable techniques in MVCC |
Дата | |
Msg-id | b0f3f5a10912170200t12810798m5ee0c5cc31b0c6fa@mail.gmail.com обсуждение исходный текст |
Ответ на | Update on true serializable techniques in MVCC ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-hackers |
[ Forgot the list, resending. ] 2009/12/16 Boszormenyi Zoltan <zb@cybertec.at>: > Robert Haas írta: > >> On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> >>> On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera >>> <alvherre@commandprompt.com> wrote: >>> >>>> So you'd have to disable HOT updates when true serializability was >>>> active? >>> >>> I thought about that, but I don't think so. HOT only applies to >>> updates, and predicate locking only applies to inserts. Unless I have >>> my head in the sand? >> >> Err, no, wait. Predicate locking can apply to updates, but since HOT >> updates never update an indexed column, I think we might still be OK? > > A predicate can include columns from an index plus others. > Am I missing something? This whole concept ("next-key locking") also applies in case there are no indexes. In the case of a table scan, the "next key" is either the next row relative to the scanned range (if the DBMS supports the notion of non-full table scans, for example if the table contents are themselves stored in sorted order), or something that indicates that the whole table was scanned (i.e., a table lock). Therefore, with next-key locking you better don't have too many table scans if you want to have any concurrent transactions. Nicolas
В списке pgsql-hackers по дате отправления: