Re: new hashing function - Mailing list pgsql-hackers

From Neil Conway
Subject Re: new hashing function
Date
Msg-id 1015183075.5258.31.camel@jiro
Whole thread Raw
In response to Re: new hashing function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 2002-03-03 at 12:31, Tom Lane wrote:
> Neil Conway <nconway@klamath.dyndns.org> writes:
> > I haven't looked at the implementation of hash joins; if they happen to
> > use this hash function as well, that would be another informative
> > situation to benchmark.
> 
> Hash joins use some chosen-at-random hashing code of their own; see
> hashFunc() in src/backend/executor/nodeHash.c.  One of the things on my
> to-do list has been to replace that with the datatype-specific hash
> functions used for indexing/caching, since the latter seem better
> engineered (even before your improvements).

Okay, I'll implement this.

> BTW, I don't particularly approve of the parts of this patch that
> simply remove unused arguments from various routines.  You aren't
> going to save very many cycles that way, and you are reducing
> flexibility (eg, the changes to remove nkeys would interfere with
> trying to make hash indexes support multiple columns).

Hmmm... I had viewed removing extra, unused functions to arguments as
basically code cleanup. But I see your point -- although really, the
future purpose behind the extra arguments should probably be
documented... I'll review my changes and remove the ones that seem to
have some future benefit.

Thanks for the feedback Tom.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: new hashing function
Next
From: Tom Lane
Date:
Subject: Followup: Syscaches should store negative entries, too