Re: planner/optimizer question
От | Tom Lane |
---|---|
Тема | Re: planner/optimizer question |
Дата | |
Msg-id | 14614.1083428488@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: planner/optimizer question (Jochem van Dieten <jochemd@oli.tudelft.nl>) |
Список | pgsql-performance |
Jochem van Dieten <jochemd@oli.tudelft.nl> writes: > The moment the heap tuple is updated/deleted the visible-to-all > flag needs to be set to false again in all indexes. This is > critical, Exactly. This gets you out of the hint-bit semantics and into a ton of interesting problems, such as race conditions. (Process A determines that tuple X is visible-to-all, and goes to update the index tuple. Before it can reacquire lock on the index page, process B updates the heap tuple and visits the index to clear the flag bit. Once A obtains lock it will set the flag bit. Oops.) Basically what you are buying into with such a thing is multiple copies of critical state. It may be only one bit rather than several words, but updating it is no less painful than if it were a full copy of the tuple's commit status. regards, tom lane
В списке pgsql-performance по дате отправления: