Re: Next Steps with Hash Indexes
От | Dilip Kumar |
---|---|
Тема | Re: Next Steps with Hash Indexes |
Дата | |
Msg-id | CAFiTN-ukrcU-q==a-W2Y-P9bX1Guii3gUf-WFXd73T3xGC1RxA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Next Steps with Hash Indexes (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Next Steps with Hash Indexes
|
Список | 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 по дате отправления: