Horton

Re: Hash Indexes

Jesper Pedersen <jesper.pedersen@redhat.com>

View thread View on postgr.es
From: Jesper Pedersen <jesper.pedersen@redhat.com>
To: Amit Kapila <amit.kapila16@gmail.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-16T18:58:25Z
Lists: pgsql-hackers

Attachments

On 09/16/2016 03:18 AM, Amit Kapila wrote:
>> 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.
>

Attached is 100,000.

>> 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.

Thanks !

> 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.
>

Like Robert said, hashscan.c can always come back, and it would take a 
call-stack out of the 'am' methods.

Best regards,
  Jesper

Commits

  1. Remove _hash_wrtbuf() in favor of calling MarkBufferDirty().

  2. Fix race introduced by 6d46f4783efe457f74816a75173eb23ed8930020.

  3. Improve hash index bucket split behavior.

  4. Reduce pinning and buffer content locking for btree scans.