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

On Sat, Jan 20, 2018 at 4:24 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Fri, Sep 29, 2017 at 8:20 PM, Alexander Korotkov
> <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > On Fri, Sep 8, 2017 at 4:07 AM, Thomas Munro <
> thomas(dot)munro(at)enterprisedb(dot)com>
> > wrote:
> >>
> >> Hi Shubham,
> >>
> >> On Tue, Jun 27, 2017 at 9:21 PM, Shubham Barai <
> shubhambaraiss(at)gmail(dot)com>
> >> wrote:
> >> > If these two hash keys (78988658 and 546789888) mapped to the same
> >> > bucket, this will result in false serialization failure.
> >> > Please correct me if this assumption about false positives is wrong.
> >>
> >> I wonder if there is an opportunity to use computed hash values
> >> directly in predicate lock tags, rather than doing it on the basis of
> >> buckets. Perhaps I'm missing something important about the way that
> >> locks need to escalate that would prevent that from working.
> >
> >
> > +1,
> > Very nice idea! Locking hash values directly seems to be superior over
> > locking hash index pages.
> > Shubham, do you have any comment on this?
> >
>
> 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.

> However, do we really need it for implementing predicate locking for
> hash indexes? If we look at the "Index AM implementations" section of
> README-SSI, it doesn't seem to be required. Basically, if we look at
> the strategy of predicate locks in btree [1], it seems to me locking
> at page level for hash index seems to be a right direction as similar
> to btree, the corresponding heap tuple read will be locked.
>

Btree uses leaf-pages locking because it supports both range searches
and exact value searches. And it needs to detect overlaps between
these two kinds of searches. Therefore, btree locks leaf-pages in both
cases. Hash index case is different. Hash index doesn't support and
isn't going to support range searches. Assuming, that hash index
supports only exact value searches, locking hash values would be
superior over page locking (unless I'm missing something), because
it would provide better locality of locks.

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