Hannu Krosing wrote: <blockquote cite="mid:1189087192.7470.16.camel@hannu-laptop" type="cite"><blockquote
type="cite"><blockquotetype="cite"><pre wrap="">One approahc is not to mix hashes, but to partition the hash, so that
each column gets its N bits in the hash. </pre></blockquote><pre wrap="">How does that help? You still need all
thekeys to find out which
bucket to look in. </pre></blockquote><pre wrap="">
no. you need to look at only the buckets where that part of hash matches
say you allocate bits 4-7 for column 2 and then need to look up column 2
value with hash 3 . here you need to look at only buckets N*16 + 3, that
is, you need to examine only each 16th bucket
</pre></blockquote><br /> I don't like the truncating hash suggestion because it limits the ability of a hash code to
uniquelyidentify a key.<br /><br /> If a user requires the ability to search on both (column1) and (column1, column2),
theycan create two hash indexes and the planner can decide which to use.<br /> Or, they can use a btree. I think hash
hasa subset of uses where it would be a significant gain, and focus should be spent on this subset.<br /><br />
Cheers,<br/> mark<br /><br /><pre class="moz-signature" cols="72">--
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>
