Hi Jeff, > At this point, the bar is quite high for convincing people to use them.
I agree with that, but I think there are still a decent number of users who are using hash indexes for different reasons. I also did some research this afternoon and found that Postgres is the only mainline DB that still provides an on-disk hash index. So either we are wrong, or that could be our competitive edge on certain use cases. I am personally not an expert on hash indexes, so I am not sure which one I will end up with. Andres said, the long keys problem with btrees is > incidental, and can be solved other ways. Looks like this is an interesting problem. I do agree that if there is any potential optimization for btree, we should take it all. If nobody volunteers, I can create a different thread and create a POC for it after 19 GAed. > If there's no index on (x) but there's an index on (f(x)), then we can > see if f is a member of a hash opclass, or if it's IMMUTABLE & > LEAKPROOF, and I think that's enough. I am not sure. I know some types' = has special logic, where it may not mean they are the same. For example, 'ABC' = 'abc' is true with a case-insensitive collation. But md5() gives different results. Thanks, Shihao
