Gregory Stark <[EMAIL PROTECTED]> writes:
> hashany of a 4-byte value degenerates to pretty much just a call to mix().
> Perhaps we should just expose a hash12() that takes three integers and calls
> mix() on them like hash_any does.
I don't see any use for that, but probably there is a use in has
Josh Berkus <[EMAIL PROTECTED]> writes:
> Tom,
>> The problem is that this is not a back-patchable
>> answer, because changing the hash functions would corrupt existing hash
>> indexes.
> Does anyone *use* hash indexes?
We get bug reports on 'em, so yes ...
regards, tom
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The best idea I can come up with for the back branches is
> to make ExecHashGetBucketAndBatch do hash_any internally, say
hashany of a 4-byte value degenerates to pretty much just a call to mix().
Perhaps we should just expose a hash12() that takes three
Tom,
> The problem is that this is not a back-patchable
answer, because changing the hash functions would corrupt existing hash
indexes.
Does anyone *use* hash indexes?
Comments, better ideas?
I was just talking to Luke today and he said they had a considerable
amount of cleanup on hash
I was idly thinking about Joseph Shraibman's problem here:
http://archives.postgresql.org/pgsql-general/2007-05/msg01011.php
in which a large hash join seemed to be blowing out memory.
By chance I tried the following test case:
js=# create table ml (jid int);
CREATE TABLE
js=# insert into ml selec
