Hi CK,

Diese Reorga würde bedeuten den gesamten Hash auf der Platte
umzuschreiben (!), [...]

Einer der Gruende, warum ich von einem Hash-Index ueber das Archiv
nicht ueberzeugt war.

ich meinte dir Reorga eines K_i hashes.

[...] ausserdem müßte ich erst festtellen dass überhaupt "zu viele"
Kolisionen da sind, was ja auch kostet.

Na, bei einer gleichmaessigen Hash-Funktion ist der Aufwand fuer das
Feststellen O(1): man kriegt ja mit, wieviele Elemente der Hash hat.

wie meinste das ... du meinst die Zahl der Kollisionen ergibts sich als Schätzwert aus der Zahl der Einträge, die irgendwann mitprotokolliert wurden?

Wenn die Hashfkt mit der Grundmenge aus dem Forum wirklich so nah am theoretischen Optimum arbeitet, sollte es IMHO auch egal sein welche Bits ich maskiere. Solche Kollisisonsoptimierungen machen nur als Korrektivum Sinn, also wenn überhaupt erst in einer späteren Phase betrachten.

Man könnte übrigens auch schlichtweg die Gesamtzahl der Kollisionen
in einem K_i mitzählen, häufen sich die Plattenzugriffe deswegen, wärs ein Grund zu reorganisieren.

Eine andere Optimierung wäre es auch die Kollisionen die zu einer Zelle j vorhanden sind zu priorisieren, soll heißen in j steht der beliebteste, in der "Alternativzelle" der zweitbeliebteste, usw.

Aber bei einer guten Hashfkt sollte das auch keine Rolle spielen, weil zu selten sich mehrere Kollisonen auf einem j konzentrieren sollten, ohne dass sowieso das Hash verdoppelt wurde.

Tschau
  rolf