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

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] GSoC 2017: weekly progress reports (week 8)
Дата
Msg-id CAPpHfdvRQDbk17rPYevLecER5+-LUMOq4WrDgvjdkDLLsDC45w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GSoC 2017: weekly progress reports (week 8)  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: [HACKERS] GSoC 2017: weekly progress reports (week 8)  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Дерево обсуждения
On Thu, Sep 28, 2017 at 2:22 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
On Fri, Jul 28, 2017 at 7:58 AM, Shubham Barai <shubhambaraiss@gmail.com> wrote:
I am attaching a patch for predicate locking in SP-Gist index

I took a look over this patch.

newLeafBuffer = SpGistGetBuffer(index,
 GBUF_LEAF | (isNulls ? GBUF_NULLS : 0),
 Min(totalLeafSizes,
 SPGIST_PAGE_CAPACITY),
 &xlrec.initDest);
 PredicateLockPageSplit(index,
 BufferGetBlockNumber(current->buffer),
 BufferGetBlockNumber(newLeafBuffer));

You move predicate lock during split only when new leaf page is allocated.  However SP-GiST may move items to the free space of another busy page during split (see other branches in doPickSplit()).  Your patch doesn't seem to handle this case correctly.

I've more thoughts about this patch.

+ * SPGist searches acquire predicate lock only on the leaf pages.
+ During a page split, a predicate lock is copied from the original
+ page to the new page.

This approach isn't going to work.  When new tuple is inserted into SP-GiST, choose method can return spgAddNode.  In this case new branch of the tree is added.  And this new branch could probably be used by scans we made in the past.  Therefore, you need to do predicate locking for internal pages too in order to detect all the possible conflicts.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.