Re: [PATCHES] updated hash functions for postgresql v1
От | Gregory Stark |
---|---|
Тема | Re: [PATCHES] updated hash functions for postgresql v1 |
Дата | |
Msg-id | 87vdsnat0o.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: [PATCHES] updated hash functions for postgresql v1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] updated hash functions for postgresql v1
Re: [PATCHES] updated hash functions for postgresql v1 |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Jeff Davis <pgsql@j-davis.com> writes: >> I ran 5 times on both old and new code, eliminating the top and bottom >> and taking the average of the remaining 3, and I got a 6.9% performance >> improvement with the new code. > > The question that has been carefully evaded throughout the discussion > of this patch is whether the randomness of the hash result is decreased, In fairness that doesn't seem to be the case. The original patch was posted with such an analysis using cracklib and raw binary data: http://article.gmane.org/gmane.comp.db.postgresql.devel.general/105675 > marginal performance improvement in the hash function itself (which is > already shown to be barely measurable in the total context of a > hash-dependent operation...) If it's a 6% gain in the speed of Hash Join or HashAggregate it would be very interesting. But I gather it's a 6% speedup in the time spent actually in the hash function. Is that really where much of our time is going? If it's 10% of the total time to execute one of these nodes then we're talking about a 0.6% optimization... -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!
В списке pgsql-hackers по дате отправления: