On 17/09/16 06:38, Andres Freund wrote:
On 2016-09-16 09:12:22 -0700, Jeff Janes wrote:
On Thu, Sep 15, 2016 at 7:23 AM, Andres Freund <and...@anarazel.de> wrote:
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?
Because getting there requires a lot of effort, debugging it afterwards
would take effort, and maintaining it would also takes a fair amount?
Adding code isn't free.
I'm rather unenthused about having a hash index implementation that's
mildly better in some corner cases, but otherwise doesn't have much
benefit. That'll mean we'll have to step up our user education a lot,
and we'll have to maintain something for little benefit.
While I see the point of what you are saying here, I recall all previous
discussions about has indexes tended to go a bit like this:
- until WAL logging of hash indexes is written it is not worthwhile
trying to make improvements to them
- WAL logging will be a lot of work, patches 1st please
Now someone has done that work, and we seem to be objecting that because
they are not improved then the patches are (maybe) not worthwhile. I
think that is - essentially - somewhat unfair.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
