| From: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Next Steps with Hash Indexes |
| Date: | 2021-07-20 13:02:51 |
| Message-ID: | CANbhV-FN4xP7ssDK01zmcUZTxG3dRd4=P1KL+k2RsEkufgJEAA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 20, 2021 at 1:26 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> One more thing we need to think about here is when to find the right
> bucket page in the chain where we can insert the new tuple. Do we
> first try to complete the uniqueness check (which needs to scan
> through the entire bucket chain) and then again scan the bucket with
> space to insert or do we want to do it along with uniqueness check
> scan and remember it?
The latter approach, but that is just a performance tweak for later.
On a unique hash index, regular splitting means there are almost no
bucket chains more than 2 long (bucket plus overflow), so it seems
like mostly wasted effort at this point.
--
Simon Riggs http://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2021-07-20 13:12:38 | Re: POC: GROUP BY optimization |
| Previous Message | Simon Riggs | 2021-07-20 13:02:42 | Re: Next Steps with Hash Indexes |