Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Дата
Msg-id 37BD51A9-5AE4-471D-A3D1-0C98A0009ED1@yandex-team.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
> 9 апр. 2018 г., в 19:50, Teodor Sigaev <teodor@sigaev.ru> написал(а):
>>
>> 3. Why do we *not* lock the entry leaf page, if there is no match? We still need a lock to remember that we probed
forthat value and there was no match, so that we conflict with a tuple that might be inserted later. 
>> At least #3 is a bug. The attached patch adds an isolation test that demonstrates it. #1 and #2 are weird, and cause
unnecessarylocking, so I think we should fix those too, even if they don't lead to incorrect results. 
>
> I can't find a hole here. Agree.
Please correct me if I'm wrong.
Let's say we have posting trees for word A and word B.
We are looking for a document that contains both.
We will read through all posting tree of A, but only through some segments of B.
If we will not find anything in B, we have to lock only segments where we actually were looking, not all the posting
treeof B. 

BTW I do not think that we lock ranges. We lock possibility of appearance of tuples that we might find. Ranges are
shortcutsfor places where we were looking.. That's how I understand, chances are I'm missing something. 

Best regards, Andrey Borodin.

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)