Re: dynamically allocating chunks from shared memory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dynamically allocating chunks from shared memory
Date: 2010-08-09 19:14:27
Message-ID: 12219.1281381267@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Markus Wanner <markus(at)bluegap(dot)ch> writes:
> However, I'd like to get back to the original intent of the posted
> patch. Which is about dynamically allocating memory *within a fixed size
> pool*.

> That's something SRLU or shared_buffers do to some extent, but with lots
> of limitations. And without the ability to move free memory between
> sub-systems (i.e. between different SLRU buffers).

As far as SLRU is concerned, the already-agreed-to plan is to get rid of
the separate arenas for SLRU and merge those things into the main shared
buffers arena. IIRC, the motivation for designing SLRU the way it is
was to ensure that SLRU uses couldn't be starved for memory due to high
demand for shared buffers. But that was back when people frequently ran
PG with only a few meg for shared buffers; I think that worry is
obsolete.

So I don't see this patch as offering anything at all that we care about
so far as the core server is concerned. Maybe there are extensions that
need it badly enough to justify such a feature in core, but SLRU is not
a good argument for it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-09 19:20:21 Re: dynamically allocating chunks from shared memory
Previous Message Markus Wanner 2010-08-09 19:11:48 Re: dynamically allocating chunks from shared memory