Re: Slowing UPDATEs inside a transaction
От | Matt Burke |
---|---|
Тема | Re: Slowing UPDATEs inside a transaction |
Дата | |
Msg-id | 4D70AF32.7020706@icritical.com обсуждение исходный текст |
Ответ на | Re: Slowing UPDATEs inside a transaction (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Slowing UPDATEs inside a transaction
|
Список | pgsql-performance |
Robert Haas wrote: > Old row versions have to be kept around until they're no longer of > interest to any still-running transaction. Thanks for the explanation. Regarding the snippet above, why would the intermediate history of multiply-modified uncommitted rows be of interest to anything, or is the current behaviour simply "cheaper" overall in terms of cpu/developer time? -- The information contained in this message is confidential and is intended for the addressee only. If you have received thismessage in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure,copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposesof investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire,ST5 5NH. ------------------------------------------------------------ This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ------------------------------------------------------------
В списке pgsql-performance по дате отправления: