Re: add function for creating/attaching hash table in DSM registry
От | Florents Tselai |
---|---|
Тема | Re: add function for creating/attaching hash table in DSM registry |
Дата | |
Msg-id | F2F49C7C-87A7-4410-8048-A4765C758CED@gmail.com обсуждение исходный текст |
Ответ на | Re: add function for creating/attaching hash table in DSM registry (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: add function for creating/attaching hash table in DSM registry
|
Список | pgsql-hackers |
> On 11 Jun 2025, at 4:57 PM, Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Wed, Jun 11, 2025 at 07:15:56PM +0530, Rahila Syed wrote: >>> How can one dsa_allocate in the same area as the returned dshash_table ? >>> in other words: shouldn't the state->dsa_handle be returned somehow ? >> >> +1. FWIW, Having used the DSA apis in my code, I think having the registry >> return >> the mapped dsa address or dsa handle will benefit users who use dsa_allocate >> to allocate smaller chunks within the dsa. > > I considered adding another function that would create/attach a DSA in the > DSM registry, since that's already an intermediate step of dshash creation. > We could then use that function to generate the DSA in GetNamedDSMHash(). > Would that work for your use-cases, or do you really need to use the same > DSA as the dshash table for some reason? In my case the hashtable itself stores dsa_pointers (obviously stuff allocated in the dsa as the hash table itself) so I think I can’t avoid the necessity of having it. Unless, you see a good reason not to expose it ?
В списке pgsql-hackers по дате отправления: