From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber) |
Date: | 2014-12-18 02:20:34 |
Message-ID: | 32316.1418869234@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> However, there's another way we could attack this,
> which is to invent a new hash option flag bit that says "pick a suitable
> hash function for me, assuming that all bits of the specified key size are
> significant". So instead of
> ctl.keysize = sizeof(...);
> ctl.entrysize = sizeof(...);
> ctl.hash = tag_hash;
> tab = hash_create("...", ..., &ctl,
> HASH_ELEM | HASH_FUNCTION);
> you'd write
> ctl.keysize = sizeof(...);
> ctl.entrysize = sizeof(...);
> tab = hash_create("...", ..., &ctl,
> HASH_ELEM | HASH_BLOBS);
> which would save some code space and is arguably cleaner than the
> current approach of specifying some support functions and not others.
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.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
make-dynahash-select-normal-hash-functions-1.patch | text/x-diff | 60.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-12-18 03:04:13 | Re: no test programs in contrib |
Previous Message | Etsuro Fujita | 2014-12-18 01:49:36 | Re: inherit support for foreign tables |