On Thu, Sep 15, 2016 at 7:23 AM, Andres Freund <andres@anarazel.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.