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
Re: Stating the significance of Lehman & Yao in the nbtree README |
Список | 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 по дате отправления: