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

From Amit Kapila
Subject Re: Next Steps with Hash Indexes
Date
Msg-id CAA4eK1KERd5KYbR0vj0i-f7n-=V5qNjHb1MFTXZpMigS8XiW2A@mail.gmail.com
Whole thread Raw
In response to Re: Next Steps with Hash Indexes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Next Steps with Hash Indexes  (Dilip Kumar <dilipbalaut@gmail.com>)
Re: Next Steps with Hash Indexes  (Simon Riggs <simon.riggs@enterprisedb.com>)
List pgsql-hackers
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 and as far as I can understand
this can happen in btree as well during uniqueness check. Now, I think
the other possibility could be that we do some sort of lock chaining
where we grab the lock of the next bucket before releasing the lock of
the current bucket as we do during bucket clean up but not sure about
the same.

I haven't studied the patch in detail so it is better for Simon to
pitch in here to avoid any incorrect information or if he has a
different understanding/idea.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Added schema level support for publication.
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side