Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)
Date
Msg-id 27181.1418928503@sss.pgh.pa.us
Whole thread Raw
In response to Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
I wrote:
> Here's a proposed patch along this line.  I left in oid_hash (in the
> form of a macro) so that this does not cause any API break for existing
> third-party modules.  However, no callers in our own code directly
> refer to tag_hash or oid_hash anymore.

Committed that version after some further comment wordsmithing.

On Teodor's original test cases, I see about 8% speedup compared to
the 4%-ish numbers he originally reported.  This may be random variation
or it might mean that we got a win someplace else besides tidbitmap.c.
I've not tried to sleuth it down exactly.  I am wondering though if
this suggests that it'd be worth our while to add a similar fast path
for 8-byte hash keys.  That would be quite painless to add now (with
the exception of actually coding the fast hash function, perhaps).
        regards, tom lane



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Commitfest problems
Next
From: Gavin Flower
Date:
Subject: Re: Commitfest problems