Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)
| От | Tom Lane |
|---|---|
| Тема | Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber) |
| Дата | |
| Msg-id | 27181.1418928503@sss.pgh.pa.us обсуждение |
| Ответ на | Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: hash_create API changes (was Re: speedup tidbitmap
patch: hash BlockNumber)
|
| Список | 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 по дате отправления: