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 по дате отправления: