From: | selkovjr(at)xnet(dot)com |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | "Gene Selkov, Jr(dot)" <selkovjr(at)xnet(dot)com>, pgsql-hackers(at)postgresql(dot)org, selkovjr(at)xnet(dot)com |
Subject: | Re: HASH: Out of overflow pages. Out of luck |
Date: | 2002-08-07 05:41:04 |
Message-ID: | 20020807054109.EDB98A13D@selkovjr.xnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> From: Hannu Krosing <hannu(at)tm(dot)ee>
>
> 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 ?
Yes, it works fine with BerkelyDB. I looked at both codes and I was
stupefied with their complexity. Even if there is a similar structure,
it must be very well disguised. Some of the data structures resemble
each other's counterparts; the only piece that is exactly the same
as one of the five BerkelyDB's hash functions.
The only useful experiment that I feel I am capable of making is
trying their __ham_hash5() function, with they claim is generally
better than the other four, for most purposes. But they warn in their
comments that there is no such thing as "a hash function" -- there
must be one for each purpose.
So another experiment I might try is writing an adapter for a
user-supplied hash -- that might help in figuring out the role of the
hash function in bin overflows. That should be easy enough to do, but
fixing or re-writing the access method itself -- I'm sorry: the level
of complexity scares me. Appears like a couple man-months
(those Mythical Man-Months :).
--Gene
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2002-08-07 08:02:33 | Re: Open 7.3 items |
Previous Message | Curt Sampson | 2002-08-07 05:30:02 | Re: CLUSTER and indisclustered |