Re: [PATCHES] updated hash functions for postgresql v1

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Kenneth Marshall <ktm(at)rice(dot)edu>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] updated hash functions for postgresql v1
Date: 2009-01-10 18:57:27
Message-ID: 87vdsnat0o.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Jeff Davis <pgsql(at)j-davis(dot)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!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-01-10 19:05:36 Re: [SPAM] Re: posix_fadvise v22
Previous Message Jeff Davis 2009-01-10 18:56:15 Re: [PATCHES] updated hash functions for postgresql v1