Hi,
On 07/22/2010 01:04 PM, Robert Haas wrote:
> Well, shared_buffers has to be allocated as one contiguous slab
> because we index into it that way. So I don't really see how
> dynamically allocating memory could help. What you'd need is a
> different system for assigning buffer tags, so that a particular tag
> could refer to a buffer with either kind of contents.
Hm.. okay, then it might not be that easy. Thanks for pointing that out.
> That's sort of approaching the question from the opposite end from
> what I was concerned about - I was wondering why you need a unicast
> message-passing system.
Well, the initial Postgres-R approach, being based on Postgres
6.4.something used unix pipes. I coded imessages as a replacement.
Postgres-R basically uses imessages to pass around change sets and other
information required to keep replicas in sync. The thinking in terms of
message passing seems to originate from the GCS, which in itself is a
message passing system (with some nice extras and varying delivery
guarantees).
In Postgres-R the coordinator process receives messages from the GCS,
does some minor controlling and book-keeping, but basically passes on
the data via imessages to a backrgound worker.
Of course, as mentioned in the bgworker patch, this could be done
differently. Using solely shared memory, or maybe SLRU to store change
sets. However, I certainly like the abstraction and guarantees such a
message passing system provides. It makes things easier to reason about,
IMO.
For another example, see the bgworker patches, steps 1 and 2, where I've
changed the current autovacuum infrastructure to use imessages (between
launcher and worker).
[ And I've heard saying that current multi-core CPU designs tend to like
message passing systems. Not sure how much that applies to imessages
and/or how it's used in bgworkers or Postgres-R, though. ]
That much about why using a unicast message-passing system.
Regards
Markus Wanner