On Sat, Jan 10, 2009 at 01:57:27PM -0500, Gregory Stark wrote:
> 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...
>
The Greenplum test did show a 5% increase in performance with the replacement
functions in March.
Regards,
Ken
