Re: Number of buckets/partitions of dshash
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Number of buckets/partitions of dshash |
Дата | |
Msg-id | 20181022.125935.123659668.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Number of buckets/partitions of dshash ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>) |
Ответы |
RE: Number of buckets/partitions of dshash
|
Список | pgsql-hackers |
Hello. At Fri, 12 Oct 2018 06:19:12 +0000, "Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com> wrote in <4E72940DA2BF16479384A86D54D0988A6F1C1779@G01JPEXMBKW04> > Hi, let me clarify my understanding about the $title. > > It seems that the number of hash partitions is fixed at 128 in dshash and > right now we cannot change it unless dshash.c code itself is changed, right? > > According to the comment of dshash.c, DSHASH_NUM_PARTITIONS could be runtime parameter in future. > Are there someone working on it? > (I want to do it, but TBH I cannot promise it because of some other work.) > > In my current development for allocating catalog cache on the shared memory[1] > I'm trying to put hash table of each CatCache to the shared memory using dshash. > The number of buckets for CatCache is pre-defined by cacheinfo and most of them is under 128 like 8 or 16. > 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. > [1] https://www.postgresql.org/message-id/4E72940DA2BF16479384A86D54D0988A567B9245%40G01JPEXMBKW04 regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: