Re: can we publish a aset interface? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: can we publish a aset interface?
Date
Msg-id 9702.1283870433@sss.pgh.pa.us
Whole thread Raw
In response to can we publish a aset interface?  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: git: uh-oh
Next
From: Ron Mayer
Date:
Subject: Re: Synchronization levels in SR