Re: Next Steps with Hash Indexes

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Next Steps with Hash Indexes
Дата
Msg-id CAA4eK1KERd5KYbR0vj0i-f7n-=V5qNjHb1MFTXZpMigS8XiW2A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Next Steps with Hash Indexes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Next Steps with Hash Indexes  (Dilip Kumar <dilipbalaut@gmail.com>)
Re: Next Steps with Hash Indexes  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Added schema level support for publication.
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side