On Mon, Aug 9, 2010 at 12:03 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> On Mon, Aug 9, 2010 at 11:02 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> > I am not sure threads would greatly help us. ?The major problem is that
>> > all of our our structures are currently contiguous in memory for quick
>> > access. ?I don't see how threading would help with that. ?We could use
>> > realloc(), but we can do the same in shared memory if we had a chunk
>> > infrastructure, though concurrent access to that memory would hurt us in
>> > either threads or shared memory.
>> >
>> > Fundamentally, recreating the libc memory allocation routines is not
>> > that hard. ?(Everyone has to detach from the shared memory segment, but
>> > they have to stop using it too, so it doesn't seem that hard.)
>>
>> I actually don't think that's true. The advantage (and disadvantage)
>> of using threads is that everything runs in one address space. So you
>> just allocate more memory and everyone immediately sees it. In a
>> process environment, that's not the case: to expand or shrink the size
>> of the shared memory arena, everyone needs to explicitly change their
>> own mapping.
>
> You can't expand the size of malloc'ed memory --- you have to call
> realloc(), and then you effectively get a new pointer. Shared memory
> has a similar limitation. If you allocate shared memory in chunks so
> you don't need to change the location, you are effectively doing another
> malloc(), like you would in a threaded process.
The point isn't what happens when you resize individual chunks; it's
what happens when you need to expand the arena.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company