From: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
---|---|
To: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: fix lock contention for HASHHDR.mutex |
Date: | 2016-01-27 15:12:47 |
Message-ID: | 20160127181247.4b51ea90@fujitsu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> This comment certainly requires some changes.
Fixed.
> BTW, could you explain why init_table_size was two times less than
> max_table_size?
I have no clue. My best guess is that it was a reasonable thing to do in
the past. Then somebody changed a code and now there is little reason
to use init_table_size for partitioned tables.
> Why did you delete these two lines? I wonder if you should rewrite
> them instead?
```
MemSet(hctl, 0, sizeof(HASHHDR));
- hctl->nentries = 0;
- hctl->freeList = NULL;
```
These fields were initialized with zero values twice. It makes little
sense to me.
> As far as I understood, this number was obtained experimentally?
> Maybe you should note that in the comment.
These numbers are very platform specific and will be outdated very
soon. I recall that my code was criticized for including exact numbers
not a long time ago. So I suggest to keep this part as is.
> For example, if you have nelem=25 and partitions_number=6.
> 25 / 6 = 4. And then you allocate 24 nelems, while 1 is lost.
Agree. Fixed.
> Except mentioned notes, I suppose the patch is good enough
I guess I will mark this patch as "Ready for Committer" then.
Attachment | Content-Type | Size |
---|---|---|
dynahash-optimization-v12.patch | text/x-patch | 18.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jinhua Luo | 2016-01-27 15:18:20 | Re: insert/update performance |
Previous Message | Amit Kapila | 2016-01-27 13:30:35 | WAL Re-Writes |