Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index

On Sun, Jan 28, 2018 at 7:28 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Jan 25, 2018 at 7:29 PM, Alexander Korotkov
> <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>>> As Shubham seems to be running out of time, I thought of helping him
>>> by looking into the above-suggested idea. I think one way to lock a
>>> particular hash value is we can use TID of heap tuple associated with
>>> each index entry (index entry for the hash index will be hash value).
>>
>>
>> Sorry, I didn't get what do you particularly mean. If locking either TID of
>> associated heap tuple or TID of hash index tuple, then what will we lock
>> in the case when nothing found? Even if we found nothing, we have
>> to place some lock according to search key in order to detect cases when
>> somebody has inserted the row which we might see according to that search
>> key.
>>
>
> Okay, but if you use hash value as lock tag (which is possible) how
> will we deal with things like page split? I think even if use
> blocknumber/page/bucketnumber corresponding to the hash value along
> with hash value in lock tag, then also it doesn't appear to work. I
> think using page level locks for index makes sense, especially because
> it will be convinient to deal with page splits.
>

What I intend to say here is that we already have a mechanism like
PredicateLockPageSplit() which can deal with predicate locks during
page split if we operate at page level. However, if we want to go for
has value locking technique, it can be quite complex and expensive to
make it work as we have to search all the locks that belong to the
bucket being split and then move them for the new bucket.

Alexander/Thomas, do you have better ideas to make it work, otherwise,
I think we can proceed to review the Shubham's current approach/patch?

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