Zdenek Kotala <zdenek.kot...@sun.com> writes:
> Tom Lane pÃÅ¡e v ne 24. 05. 2009 v 18:46 -0400:
>> In any case, the barriers to implementing 8.3-style hash indexes in 8.4
>> are pretty huge: you'd need to duplicate not only the hash AM code, but
>> also all the hash functions, and therefore all of the hash pg_amop and
>> pg_amproc entries.
> I'm not sure if I need duplicate functions. Generally yes but It seems
> to me that hash index does not changed functions behavior and they could
> be shared at this moment.
No, the behavior of the hash functions themselves changed during 8.4.
Twice, even:
2008-04-06 12:54 tgl
* contrib/dblink/expected/dblink.out,
contrib/dblink/sql/dblink.sql, src/backend/access/hash/hashfunc.c,
src/include/catalog/catversion.h,
src/test/regress/expected/portals.out,
src/test/regress/sql/portals.sql: Improve hash_any() to use
word-wide fetches when hashing suitably aligned data. This makes
for a significant speedup at the cost that the results now vary
between little-endian and big-endian machines; which forces us to
add explicit ORDER BYs in a couple of regression tests to preserve
machine-independent comparison results. Also, force initdb by
bumping catversion, since the contents of hash indexes will change
(at least on big-endian machines).
Kenneth Marshall and Tom Lane, based on work from Bob Jenkins.
This commit does not adopt Bob's new faster mix() algorithm,
however, since we still need to convince ourselves that that
doesn't degrade the quality of the hashing.
2009-02-09 16:18 tgl
* src/: backend/access/hash/hashfunc.c,
include/catalog/catversion.h,
test/regress/expected/polymorphism.out,
test/regress/expected/union.out, test/regress/sql/polymorphism.sql:
Adopt Bob Jenkins' improved hash function for hash_any(). This
changes the contents of hash indexes (again), so bump catversion.
Kenneth Marshall
So as far as I can see, you need completely separate copies of both
hash_any() and the SQL-level functions that call it. I'm not really
seeing that the proposed refactoring makes this any easier. You might
as well just copy-and-paste all that old code into a separate set of
files, and not worry about what is in access/hash.h.
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
