| 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 18:48:23 |
| Message-ID: | 27181.1418928503@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Flower | 2014-12-18 19:03:02 | Re: Commitfest problems |
| Previous Message | Joshua D. Drake | 2014-12-18 18:44:13 | Re: Commitfest problems |