On Mon, 2002-08-05 at 07:26, Gene Selkov, Jr. wrote:
> Hi Everybody!
>
> I'm sorry I dropped out for so long -- was switching jobs and was on
> the verge of deportation for a while. Still not entirely back to
> normal, but can raise my head and look around.
>
> The first thing I discovered in the current version (7.2.1) -- as well
> as in 7.1.3 -- seems to be an old problem with the hash am. It's
> clustering too much.
...
> The quality of the hash function can be a factor here, but probably
> not the major one. I was able to jack my limit up to over 3.7M rows by
> reversing the order of bytes in hashvarlena() -- I made the pointer go
> down instead of up. That spread the hash values more sparsely, but it
> failed with the same message when I fed it with more than 4M rows.
>
> I saw Tom answer a similar question a year ago, by saying that the
> hash access method is poorly supported and that there is no advantage
> to using it. I am not sure about the former, but the latter is not
> entirely true: we saw at least 20% gain in performance when we
> switched from btree to hash, and my boss considers 20% a big enough
> improvement. Besides, he knows the database theory and he is a
> long-time BerkelyDB user,
As BerkelyDB came into being by splitting index methods out of an early
version of Postgres, it should still have some similar structure left,
so one possibility is to check what they are doing to not be that bad.
Have you tried to index your dataset into a BerkelyDB database ?
> and in his world, hash is greatly superior
> to btree, so he is wondering why are the postgres implementations so
> close. Besides, it's a tough challenge to explain it to a Libertarian
> that he'd better not do something.
-------------
Hannu
