Robert Haas <robertmh...@gmail.com> writes:
> After some further thought, I propose the following approach to the
> issues raised on this thread:
> 1. Allow hash functions to have a second, optional support function,
> similar to what we did for btree opclasses in
> c6e3ac11b60ac4a8942ab964252d51c1c0bd8845. The second function will
> have a signature of (opclass_datatype, int64) and should return int64.
> The int64 argument is a salt. When the salt is 0, the low 32 bits of
> the return value should match what the existing hash support function
> returns. Otherwise, the salt should be used to perturb the hash
> calculation.
+1
> 2. Introduce a new hash opfamilies here which are more faster, more
> portable, and/or better in other ways than the ones we have today.
This part seems, uh, under-defined and/or over-ambitious and/or unrelated
to the problem at hand. What are the concrete goals?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
