On Mon, Aug 9, 2010 at 12:03 PM, Bruce Momjian <br...@momjian.us> wrote: > Robert Haas wrote: >> On Mon, Aug 9, 2010 at 11:02 AM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
