From: | "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Number of buckets/partitions of dshash |
Date: | 2018-11-06 23:55:06 |
Message-ID: | 4E72940DA2BF16479384A86D54D0988A6F1EE1CD@G01JPEXMBKW04 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>From: Kyotaro HORIGUCHI [mailto:horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp]
>> This would cause some waste of memory on DSA because some partitions (buckets)
>is allocated but not used.
>>
>> So I'm thinking that current dshash design is still ok but flexible
>> size of partition is appropriate for some use cases like mine.
>>
>> Do you have any thoughts?
>
>We could do that easily, but shouldn't we find a way to reduce or eliminate the impact
>of locking first? dshash needs to hold partition lock while the caller is examining a
>returned entry.
Thanks for the comment.
I agreed.
It would take a long time to achieve it but as you've pointed out
finding way to minimize the locking time seems benefit for everyone and first priority.
Regards,
Takeshi Ideriha
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-11-07 00:05:31 | Re: ON COMMIT actions and inheritance |
Previous Message | Andrew Gierth | 2018-11-06 23:44:56 | Re: First-draft release notes for back-branch releases |