Re: Hash Indexes
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Jesper Pedersen <jesper.pedersen@redhat.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, Mithun Cy <mithun.cy@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-09-16T07:18:10Z
Lists: pgsql-hackers
On Thu, Sep 15, 2016 at 10:38 PM, Jesper Pedersen <jesper.pedersen@redhat.com> wrote: > On 09/15/2016 02:03 AM, Amit Kapila wrote: >>> >>> Same thing here - where the fields involving the hash index aren't >>> updated. >>> >> >> Do you mean that for such cases also you see 40-60% gain? >> > > No, UPDATEs are around 10-20% for our cases. > Okay, good to know. >> >> It might be useful to test with higher number of rows because with so >> less data contention is not visible, > > > Attached is a run with 1000 rows. > I think 1000 is also less, you probably want to run it for 100,000 or more rows. I suspect that the reason why you are seeing the large difference between btree and hash index is that the range of values is narrow and there may be many overflow pages. >> > > I think for CHI is would be Robert's and others feedback. For WAL, there is > [1]. > I have fixed your feedback for WAL and posted the patch. I think the remaining thing to handle for Concurrent Hash Index patch is to remove the usage of hashscan.c from code if no one objects to it, do let me know if I am missing something here. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Remove _hash_wrtbuf() in favor of calling MarkBufferDirty().
- 25216c989384 10.0 landed
-
Fix race introduced by 6d46f4783efe457f74816a75173eb23ed8930020.
- 2f4193c3509a 10.0 cited
-
Improve hash index bucket split behavior.
- 6d46f4783efe 10.0 landed
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited