On Mar 18, 2011, at 12:34 PM, Nicholson, Brad (Toronto, ON, CA) wrote:
>>> b) its own postgresql processes (many of them) running in memory
>>
>> I believe this is entirely a function of client connections.
>
> With a single instance, you can use connection pooling to reduce the overall number of backend connections which will
reduceyour memory footprint.
Er, right, for some reason I was thinking I could use connection pooling against multiple clusters, but now that I
thinkabout it that doesn't make much sense, does it?
>>
>>> c) its own shared_buffers in memory.
>>
>> Given that each application will be independent, I don't see a
>> different between clusters and schemas here either.
>
> The difference is that in a single cluster, a single instance is going to make decisions about what data to cache or
not. This is an overly simplified example - but illustrates the point. Say you have 4GB of RAM available to dedicate
toa shared buffers on a server, and two databases (DB A and DB B) to run. You either set up a single instance with a
4GBpool, or two instances with 2GB pools each. Let's say that DB A gets really busy, and DB B is not. In the shared
instanceapproach, the instance can evict buffers cached for DB B in order to load buffers needed for DB A. In the
splitinstance, you can't.
Ah, that's an illustrative example. Thanks.
OK, so are there any good ways to keep a bad/clueless user from gumming up a whole cluster? Something like
statement_timeout,but for transactions, seems like it would be idle.
