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

On Wed, Jul 23, 2014 at 11:19 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Tue, Jul 22, 2014 at 8:59 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> > Okay, but how does this justify to add below new text in README.
> > + Even with these read locks, Lehman and Yao's approach obviates the
> > + need of earlier schemes to hold multiple read locks concurrently when
> > + descending the tree as part of servicing index scans (pessimistic lock
> > + coupling).
> >
> > Actually I think putting it can lead to inconsistency in the README.
> > Currently it indicates that our algorithm is different from L&Y w.r.t
taking
> > Read Locks and has given explanation for same.
>
> Not really. Firstly, that sentence acknowledges that there are read
> locks where L&Y assume there will not be. "Even with these read locks"
> references the first paragraph, where it is stated the Postgres
> B-Trees still acquire read locks while descending the tree.

I think here you want to state that the difference in Postgres is "as we are
using L & Y approach, it don't need to hold *multiple* read locks
concurrently",
and L & Y approach which obviates this need is explained in second line
(which indicates the importance of maintaining right-links and high-keys to
detect and recover from page splits).

As such there is no problem in saying the way you have mentioned, but
I feel it would be better if we can mention the mechanism of _bt_search()
as quoted by you upthread in the first line.
"> In more concrete terms, _bt_search() releases and only then acquires
> read locks during a descent of the tree (by calling
> _bt_relandgetbuf()), and, perhaps counterintuitively, that's just
> fine."

One more point, why you think it is important to add this new text
on top? I think adding new text after "Lehman and Yao don't require read
locks, .." paragraph is okay.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com