Re: planner/optimizer question

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: planner/optimizer question
Дата
в 13:23:08
Msg-id
14614.1083428488@sss.pgh.pa.us
Ответ на
Re: planner/optimizer question (Jochem van Dieten)
Список
Дерево обсуждения
Re: planner/optimizer question Jochem van Dieten <jochemd@oli.tudelft.nl>
Re: planner/optimizer question Manfred Koizar <mkoi-pg@aon.at>
Re: planner/optimizer question Tom Lane <tgl@sss.pgh.pa.us>
Re: planner/optimizer question Jochem van Dieten <jochemd@oli.tudelft.nl>
Re: planner/optimizer question Tom Lane <tgl@sss.pgh.pa.us>
Re: planner/optimizer question "Gary Doades" <gpd@gpdnet.co.uk>
Re: planner/optimizer question Manfred Koizar <mkoi-pg@aon.at>
Re: planner/optimizer question "Jochem van Dieten" <jochemd@oli.tudelft.nl>
Jochem van Dieten  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 по дате отправления
От: Gary Doades
Дата:
Сообщение: Re: planner/optimizer question
От: Dave Cramer
Дата:
FAQ