On Wed, Jul 23, 2014 at 11:19 AM, Peter Geoghegan <
pg@heroku.com> wrote:
> On Tue, Jul 22, 2014 at 8:59 PM, Amit Kapila <
amit.kapila16@gmail.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.
