Re: new hashing function

From: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: new hashing function
Date: 2002-03-03 19:17:54
Message-ID: 1015183075.5258.31.camel@jiro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2002-03-03 at 12:31, Tom Lane wrote:
> Neil Conway <nconway(at)klamath(dot)dyndns(dot)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(at)rogers(dot)com>
PGP Key ID: DB3C29FC

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-03-03 19:32:13 Followup: Syscaches should store negative entries, too
Previous Message Tom Lane 2002-03-03 18:48:52 Re: new hashing function