Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
От | Shubham Barai |
---|---|
Тема | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Дата | |
Msg-id | CALxAEPvEUjZ10-uELtoKdebBX-3KPN2Ub=7gJypaf7HQzNjuKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
|
Список | pgsql-hackers |
On 1 October 2017 at 01:47, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
On Sat, Sep 30, 2017 at 6:12 PM, Shubham Barai <shubhambaraiss@gmail.com> wrote:I have made changes according to your suggestions. Please have a look at the updated patch.I am also considering your suggestions for my other patches also. But, I will need some time tomake changes as I am currently busy doing my master's.I don't understand why sometimes you call PredicateLockPage() only when fast update is off. For example:@@ -94,6 +101,9 @@ scanPostingTree(Relation index, GinScanEntry scanEntry,
break; /* no more pages */
buffer = ginStepRight(buffer, index, GIN_SHARE);
+
+ if (!GinGetUseFastUpdate(index))
+ PredicateLockPage(index, BufferGetBlockNumber(buffer), snapshot);
}
UnlockReleaseBuffer(buffer);But sometimes you call PredicateLockPage() unconditionally.@@ -131,6 +141,8 @@ collectMatchBitmap(GinBtreeData *btree, GinBtreeStack *stack,
attnum = scanEntry->attnum;
attr = btree->ginstate->origTupdesc->attrs[attnum - 1];
+ PredicateLockPage(btree->index, stack->buffer, snapshot);
+
for (;;)
{
Page page;As I understand, all page-level predicate locking should happen only when fast update is off.Also, despite general idea is described in README-SSI, in-code comments would be useful.
Hi Alexander,
Yes, page-level predicate locking should happen only when fast update is off.
Actually, I forgot to put conditions in updated patch. Does everything else look ok ?
Kind Regards,
Shubham В списке pgsql-hackers по дате отправления: