Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)
От | Tom Lane |
---|---|
Тема | Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4) |
Дата | |
Msg-id | 4959.1243271240@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4) (Zdenek Kotala <Zdenek.Kotala@Sun.COM>) |
Ответы |
Re: [PATCH] cleanup hashindex for pg_migrator hashindex
compat mode (for 8.4)
|
Список | 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 по дате отправления: