Re: Next Steps with Hash Indexes - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Next Steps with Hash Indexes
Date
Msg-id CAFiTN-ukrcU-q==a-W2Y-P9bX1Guii3gUf-WFXd73T3xGC1RxA@mail.gmail.com
Whole thread Raw
In response to Re: Next Steps with Hash Indexes  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Next Steps with Hash Indexes
List pgsql-hackers
On Fri, Aug 13, 2021 at 9:31 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Aug 12, 2021 at 8:30 PM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Thu, Aug 12, 2021 at 12:22 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > The design of the patch has changed since the initial proposal. It
> > > tries to perform unique inserts by holding a write lock on the bucket
> > > page to avoid duplicate inserts.
> >
> > Do you mean that you're holding a buffer lwlock while you search the
> > whole bucket? If so, that's surely not OK.
> >
>
> I think here you are worried that after holding lwlock we might
> perform reads of overflow pages which is not a good idea. I think
> there are fewer chances of having overflow pages for unique indexes so
> we don't expect such cases in common

I think if we identify the bucket based on the hash value of all the
columns then there should be a fewer overflow bucket, but IIUC, in
this patch bucket, is identified based on the hash value of the first
column only so there could be a lot of duplicates on the first column.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Default to TIMESTAMP WITH TIME ZONE?
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: [bug] Logical Decoding of relation rewrite with toast does not reset toast_hash