Re: Hash Indexes

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hash Indexes
Date: 2016-09-16 16:12:22
Message-ID: CAMkU=1y8NnCpVc9uYgsvG9atKHmP-Ekbphqqx0kap1wRa6hi+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 15, 2016 at 7:23 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2016-05-10 17:39:22 +0530, Amit Kapila wrote:
> > For making hash indexes usable in production systems, we need to improve
> > its concurrency and make them crash-safe by WAL logging them.
>
> One earlier question about this is whether that is actually a worthwhile
> goal. Are the speed and space benefits big enough in the general case?
> Could those benefits not be achieved in a more maintainable manner by
> adding a layer that uses a btree over hash(columns), and adds
> appropriate rechecks after heap scans?
>
> Note that I'm not saying that hash indexes are not worthwhile, I'm just
> doubtful that question has been explored sufficiently.
>

I think that exploring it well requires good code. If the code is good,
why not commit it? I would certainly be unhappy to try to compare WAL
logged concurrent hash indexes to btree-over-hash indexes, if I had to wait
a few years for the latter to appear, and then dig up the patches for the
former and clean up the bitrot, and juggle multiple patch sets, in order to
have something to compare.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sachin Kotwal 2016-09-16 16:26:39 Re: Why postgres take RowExclusiveLock on all partition
Previous Message Alex Ignatov 2016-09-16 15:18:04 Re: Parallel sec scan in plpgsql