On Wed, Jul 23, 2014 at 11:19 AM, Peter Geoghegan <p...@heroku.com> wrote: > On Tue, Jul 22, 2014 at 8:59 PM, Amit Kapila <amit.kapil...@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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
