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)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Список 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 по дате отправления:

Предыдущее
От: "Kolb, Harald (NSN - DE/Munich)"
Дата:
Сообщение: Re: Synchronous replication: Promotion of Standby to Primary
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Warnings in compile