Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index - Mailing list pgsql-hackers

From Shubham Barai
Subject Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index
Date
Msg-id CALxAEPtDewLA13HY9nx1hmeCPVoHzv-J+=Uv0vkwqxTxKa1gig@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Hi Thomas,

I have attached the rebased version of patch here.


Kind Regards,
Shubham

On 8 September 2017 at 06:37, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
Hi Shubham,

On Tue, Jun 27, 2017 at 9:21 PM, Shubham Barai <shubhambaraiss@gmail.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.

> 3) tested my patch on the current head

This no longer applies, but it's in "Needs review" status in the
Commitfest.  Could you please post a rebased version?

--
Thomas Munro
http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Jeevan Ladhe
Date:
Subject: Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?