On Thu, Sep 15, 2016 at 10:38 PM, Jesper Pedersen <jesper.peder...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
