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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Stating the significance of Lehman & Yao in the nbtree README
Дата
Msg-id CAA4eK1KhAtLAVePckLf+pppJ1_io7jz+TsSyXqmT8YwuwK_qkg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Stating the significance of Lehman & Yao in the nbtree README  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On Thu, Jul 24, 2014 at 9:28 AM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Jul 23, 2014 at 8:52 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > 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."
>
> I guess I could say that too.

Okay.

> > 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.
>
> I've added it to the top because it's really the most important point
> on Lehman and Yao. It's the _whole_ point. Consider how it's
> introduced here, for example:
> http://db.cs.berkeley.edu/jmh/cs262b/treeCCR.html
>
> Why should I "bury the lead"?

I think even if you want to keep it at top, may be we could have another
heading like : Concurrency Considerations with Lehman & Yao Approach

However, I think we can leave this point for Committer to decide. 


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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Checkpointer crashes on slave in 9.4 on windows
Следующее
От: Magnus Hagander
Дата:
Сообщение: 9.4 docs current as of