Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)
Date
Msg-id 4959.1243271240@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
Zdenek Kotala <Zdenek.Kotala@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:
Improvehash_any() to useword-wide fetches when hashing suitably aligned data.  This makesfor a significant speedup at
thecost that the results now varybetween little-endian and big-endian machines; which forces us toadd explicit ORDER
BYsin a couple of regression tests to preservemachine-independent comparison results.  Also, force initdb bybumping
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
stillneed to convince ourselves that thatdoesn'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:AdoptBob Jenkins' improved hash function for hash_any().  Thischanges the contents of
hashindexes (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


pgsql-hackers by date:

Previous
From: "Kolb, Harald (NSN - DE/Munich)"
Date:
Subject: Re: Synchronous replication: Promotion of Standby to Primary
Next
From: Tom Lane
Date:
Subject: Re: Warnings in compile