Re: Hash index todo list item

Hannu Krosing wrote:
>>> One approahc is not to mix hashes, but to partition the hash, so that
>>> each column gets its N bits in the hash.
>>>
>> How does that help? You still need all the keys to find out which
>> bucket to look in.
>>
>
> 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
>
>

I don't like the truncating hash suggestion because it limits the
ability of a hash code to uniquely identify a key.

If a user requires the ability to search on both (column1) and (column1,
column2), they can create two hash indexes and the planner can decide
which to use.
Or, they can use a btree. I think hash has a subset of uses where it
would be a significant gain, and focus should be spent on this subset.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>