Tom Lane <t...@sss.pgh.pa.us> writes: > Jeff Davis <pg...@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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
