Re: introduce dynamic shared memory registry
От | Robert Haas |
---|---|
Тема | Re: introduce dynamic shared memory registry |
Дата | |
Msg-id | CA+TgmoZRber4XLQC6PaRneh5OECakguePcFD4YUg8qJ+jB+u=g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: introduce dynamic shared memory registry (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: introduce dynamic shared memory registry
|
Список | pgsql-hackers |
On Tue, Jan 2, 2024 at 11:21 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > Are we expecting, for instance, a 128-bit UUID being used as a key and > > hence limiting it to a higher value 256 instead of just NAMEDATALEN? > > My thoughts were around saving a few bytes of shared memory space that > > can get higher when multiple modules using a DSM registry with > > multiple DSM segments. > > I'm not really expecting folks to use more than, say, 16 characters for the > key, but I intentionally set it much higher in case someone did have a > reason to use longer keys. I'll lower it to 64 in the next revision unless > anyone else objects. This surely doesn't matter either way. We're not expecting this hash table to have more than a handful of entries; the difference between 256, 64, and NAMEDATALEN won't even add up to kilobytes in any realistic scenario, let along MB or GB. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: