Horton

Re: Hash Indexes

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Jesper Pedersen <jesper.pedersen@redhat.com>, Mithun Cy <mithun.cy@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-09-21T19:35:44Z
Lists: pgsql-hackers 
On Wed, Sep 21, 2016 at 2:11 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> We are?  I thought we were trying to preserve on-disk compatibility so that
> we didn't have to rebuild the indexes.

Well, that was my initial idea, but ...

> Is the concern that lack of WAL logging has generated some subtle
> unrecognized on disk corruption?

...this is a consideration in the other direction.

> If I were using hash indexes on a production system and I experienced a
> crash, I would surely reindex immediately after the crash, not wait until
> the next pg_upgrade.

You might be more responsible, and more knowledgeable, than our typical user.

>> But is that a good thing to do?  That's a little harder to
>> say.
>
> How could we go about deciding that?  Do you think anything short of coding
> it up and seeing how it works would suffice?  I agree that if we want to do
> it, v10 is the time.  But we have about 6 months yet on that.

Yes, I think some experimentation will be needed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.