| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | signed division in hash_search_with_hash_value(ENTER) has high overhead |
| Date: | 2016-06-22 00:26:07 |
| Message-ID: | 20160622002607.mbsfsm42cxqomi4d@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
During several profile runs I've seen the division in
if (action == HASH_ENTER || action == HASH_ENTER_NULL)
{
/*
* Can't split if running in partitioned mode, nor if frozen, nor if
* table is the subject of any active hash_seq_search scans. Strange
* order of these tests is to try to check cheaper conditions first.
*/
if (!IS_PARTITIONED(hctl) && !hashp->frozen &&
hctl->freeList[0].nentries / (long) (hctl->max_bucket + 1) >= hctl->ffactor &&
!has_seq_scans(hashp))
(void) expand_table(hashp);
}
taking up significant amounts of time. Which is not particularly
surprising: A signed 64 integer division (which is what we're dealing
with here) takes up to ~100 cycles, is microcoded, and prevents
instruction level parallelism.
We could cast to unsigned long - which would be faster - but it seems
like it'd be better to compute a threshold in
init_htab()/expand_table(), and make that && hctl->freeList[0].nentries >= hctl.next_expansion
or somesuch.
I don't plan to do that, but I wanted to document it, should somebody
else be motivated to look into this.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-06-22 01:41:01 | Re: Missing checks when malloc returns NULL... |
| Previous Message | Bruce Momjian | 2016-06-22 00:22:23 | Re: Speaking of breaking compatibility...standard_conforming_strings |