On Sat, Jan 10, 2009 at 01:57:27PM -0500, Gregory Stark wrote: > 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... >
The Greenplum test did show a 5% increase in performance with the replacement functions in March. Regards, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
