Re: WAL record CRC calculated incorrectly because of underlying buffer modification

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