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

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Stating the significance of Lehman & Yao in the nbtree README
Date: 2014-09-12 17:24:53
Message-ID: CAM3SWZTNeh0tOj0K41Hx6LYfmbNaEKNbp=8gnde8tR=2QWCn4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 12, 2014 at 10:10 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-12 17:25:33 Re: jsonb format is pessimal for toast compression
Previous Message Simon Riggs 2014-09-12 17:19:00 Re: Turning off HOT/Cleanup sometimes