On Wednesday 03 December 2008 23:49:00 Scott Marlowe wrote:
> On Wed, Dec 3, 2008 at 11:05 AM, Josh Harrison <joshques@gmail.com> wrote:
> > On Wed, Dec 3, 2008 at 11:51 AM, Scott Marlowe <scott.marlowe@gmail.com>
> >
> > wrote:
> >> On Wed, Dec 3, 2008 at 8:43 AM, Josh Harrison <joshques@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > 1. Is there a limit on the number of databases that can be in a single
> >> > postgres cluster?
> >>
> >> No. I'm sure there's a practical limit into the thousands where
> >> things start to get slower.
> >>
> >> > 2. Is there any performance impacts associated with having too many
> >> > databases in a cluster?
> >>
> >> Define too many. I've run a couple hundred before without it being a
> >> problem.
> >>
> >> > 3. Is there a good magical number for this limit ?
> >>
> >> Only the one that your testing tells you there is. Got a rough guess
> >> of how many you want to run? How busy they'll be? that kind of
> >> thing.
> >
> > About 10-15 ?
>
> That's hardly any really. At that point it's more about whether or
> not your server can support all the users / access going on at once.
> 15 or 1 db in the cluster, if you've got 200 users hitting it hard
> you'll need a big server. OTOH, 100 dbs in a cluster with a dozen or
> fewer average users is just fine.
Right. This becomes most important when you tune postgresql.conf parameters,
which will apply cluster wide so need to be calculated across all databases.
The fsm settings are a good example (tracking pages across all databases),
but also things like work_mem need to account for all connections to all
databases when you think about how high you can set these. Don't forget some
of these settings (like work_mem) can be set per database using the ALTER
DATABASE command, just be careful becuase the support for backing up those
changes is spotty at best.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
