| 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: | Whole Thread | Raw Message | 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 |