Re: Deprecating Hash Indexes - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Deprecating Hash Indexes
Date
Msg-id CA+U5nMKR7ZG+6YbzqZBjawk_3u5a1QatQh90XvHn2PjkoxtU1Q@mail.gmail.com
Whole thread Raw
In response to Re: Deprecating Hash Indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 14 October 2012 17:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> As discussed on other threads, Hash Indexes are currently a broken
>> feature and bring us into disrepute.
>
> Yeah ...
>
>> Suggested actions are
>
> I find it curious that you don't even bother to list "add WAL support to
> hash indexes" as a possible solution.  It's certainly doable, and
> probably not even very much more work than something like moving hash
> support to a contrib module would be.  (Assuming that's even possible,
> which I doubt, because the core code relies on hash index opclasses even
> if not on hash indexes.)

It is doable, yes.

I think that's at least 2-3 months total work, much of it low-level
bug fixing and eventual production bug hunting. Its gone for 9.3
already, so the earliest this would see production code is Sept 2014.

It's a task beyond most people's ability and beyond the range of
professionals without funding. I don't see anyone funding a medium-low
importance feature ahead of the higher ones out there, so I don't
expect the situation to change for (more) years.

If you personally have time to spare on performance features, there
are many optimizer tasks more worthy of your attention and more
popular also, so I don't ask for a code sprint on this.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump restore error
Next
From: Tom Lane
Date:
Subject: Re: Rethinking placement of latch self-pipe initialization