Re: can we publish a aset interface?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: can we publish a aset interface?
Дата
Msg-id 9702.1283870433@sss.pgh.pa.us
обсуждение исходный текст
Ответ на can we publish a aset interface?  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I would to use a special memory context for shared data (based on
> mmap) and I like impementation of aset. There is only one difference -
> aset is based on malloc and I would to use a mmap.

> malloc() is used in AllocSetContextCreate and AllocSetAlloc. These
> procedures should be overwritten, but other code and data structures
> can be used. This step can be useful for previous discuss about some
> more comfortable maintaining of shared memory.

> What do you think about?

If you're proposing factoring aset.c into two levels, I don't think so.
That code is already a tremendous performance hot-spot and introducing
any more inefficiency into it doesn't seem like a good idea.  Especially
not for shared memory allocation, which is a feature that still has
no buy-in.  Also, you'd need to do more than just replace malloc: you'd
need to add locking capability.  That would make the code even uglier,
and slower, if it has to support locking or no locking dynamically.

Use the mcxt.c switch.  That's what it's there for.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: git: uh-oh
Следующее
От: Ron Mayer
Дата:
Сообщение: Re: Synchronization levels in SR