On Wed, Jul 21, 2010 at 2:53 PM, Markus Wanner <markus@bluegap.ch> wrote:
>> Consider also the contrary situation,
>> where the imessages stuff is not in use (even for a short period of
>> time, like a few minutes). Then we'd really rather not still have
>> memory carved out for it.
>
> Huh? That's exactly what dynamic allocation could give you: not having
> memory carved out for stuff you currently don't need, but instead being able
> to dynamically use memory where most needed. SLRU has memory (not disk
> space) carved out for pretty much every sub-system separately, if I'm
> reading that code correctly.
Yeah, I think you are right. :-(
>> I think what would be even better is to merge the SLRU pools with the
>> shared_buffer pool, so that the two can duke it out for who is in most
>> need of the limited amount of memory available.
>
> ..well, just add the shared_buffer pool to the list of candidates that could
> use dynamically allocated shared memory. It would need some thinking about
> boundaries (i.e. when to spill to disk, for those modules that /want/ to
> spill to disk) and dealing with OOM situations, but that's about it.
I'm not sure why merging the SLRU pools with shared_buffers would
benefit from dynamically allocated shared memory.
I might be at (or possibly beyond) the limit of my ability to comment
intelligently on this without looking more at what you want to use
these imessages for, but I'm still pretty skeptical about the idea of
storing them directly in shared memory. It's possible, though, that I
am all wet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company