Re: What is wrong with hashed index usage?

Dann Corbit wrote:
> > > This change strikes me as a step backwards. The existing
> > wording tells
> > > the truth; the proposed revision removes the facts in favor
> > of a blanket
> > > assertion that is demonstrably false.
> >
> > OK, which part of is "demonstrably false"? I think the old "should
> > generally be preferred" is too vague. No one has come up with a case
> > where hash has shown to be faster, and a lot of cases where
> > it is slower.
>
> I agree with Tom. Maybe it is not true for PostgreSQL that hashed
> indexes are better, but for every other database if you are doing single
> lookups and do not need to order the items sequentially, hashed indexes
> are better. What this indicates to me is that hashed indexes could
> {potentially} be much better implemented for PostgreSQL.

Yes, our implementation needs help. People who know other db's are
probably choosing hash thinking it is as good as btree in our code, and
it isn't. That's why I wanted the documentation update, and why I am
suggesting the elog(NOTICE).

I have updated the documentation to specifically mention that
PostgreSQL's hashes are slower/similar to btree.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026