Horton

Re: Hash Indexes

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Jesper Pedersen <jesper.pedersen@redhat.com>, Jeff Janes <jeff.janes@gmail.com>, Mithun Cy <mithun.cy@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-10-18T17:46:35Z
Lists: pgsql-hackers 
On 2016-10-18 13:38:14 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Tue, Oct 18, 2016 at 5:37 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> I have implemented this idea and it works for MVCC scans.  However, I
> >> think this might not work for non-MVCC scans.  Consider a case where
> >> in Process-1, hash scan has returned one row and before it could check
> >> it's validity in heap, vacuum marks that tuple as dead and removed the
> >> entry from heap and some new tuple has been placed at that offset in
> >> heap.
> 
> > Oops, that's bad.
> 
> Do we care?  Under what circumstances would a hash index be used for a
> non-MVCC scan?

Uniqueness checks, are the most important one that comes to mind.

Andres

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.