Re: Stating the significance of Lehman & Yao in the nbtree README

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Stating the significance of Lehman & Yao in the nbtree README
Дата
Msg-id CAM3SWZTNeh0tOj0K41Hx6LYfmbNaEKNbp=8gnde8tR=2QWCn4w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Stating the significance of Lehman & Yao in the nbtree README  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Stating the significance of Lehman & Yao in the nbtree README  (Kevin Grittner <kgrittn@ymail.com>)
Re: Stating the significance of Lehman & Yao in the nbtree README  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Fri, Sep 12, 2014 at 10:10 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> Gosh, I think you're making this way more complicated than it needs to
> be.  My interpretation of the above statement was that they knew
> individual page reads and writes would need to be made atomic -
> probably using some form of simple locking - but omitted that from
> their pseudocode for clarity.

That clearly isn't the case. The introductory paragraph of L&Y says
the following:

"Our solution compares favorably with earlier solutions in that the
locking scheme is simpler (no read-locks are used) and only a (small)
constant number of nodes are locked by any update process at any given
time."

They clearly and prominently state that not needing read locks is a
major advantage of their algorithm, which doesn't quite ring true.

> If this is what we're arguing about, it's completely not worth the
> time we've spent on it.

It isn't. It's a minor point, originally raised by Amit.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Turning off HOT/Cleanup sometimes
Следующее
От: Robert Haas
Дата:
Сообщение: Re: jsonb format is pessimal for toast compression