Re: Scaling concerns - Mailing list pgsql-performance

From tsuraan
Subject Re: Scaling concerns
Date
Msg-id 84fb38e30612171359r6288de69y2553be256019ba4b@mail.gmail.com
Whole thread Raw
In response to Re: Scaling concerns  (Andreas Kostyrka <andreas@kostyrka.org>)
Responses Re: Scaling concerns  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-performance
> For scaling you should consider slony. Either hangout on #slony on
> Freenode.net or ask on the mailing list if you have questions.

For some reason I had thought slony was really immature, but it
actually looks really usable.

> Intel chips => define more. There are Intel boxes known to have issues
> under specific load scenarios with PostgreSQL (again specific
> versions). To make it funnier, these are really really hard to track
> down ;)

I can't access the Intel machine right now, but it's the current
fastest Intel dual-core.  I'll figure it out tomorrow.

> Cluster. One box that applies changes, and multiple boxes that read
> the data.
>
> If you cannot afford multiple boxes from the start, design your
> application still to work with two connections: one connection to a
> user with read/write permissions, and one connecting to a user having
> only select permissions => this way you can later easily add a
> loadbalancer to the mix, and use multiple postgres boxes for reading
> stuff.

I think I'll see what I can do for that.  Is there an aggregation-type
of clustering for Postgres?  I'm thinking of something where database
information is divided between machines, rather than shared among them
as in Slony.  Sort of like the difference between RAID0 and RAID1.
Since my application is constantly adding to the database (far more is
written than is ever read), it would be nice to have a multiple-write,
single reader solution, if such a thing exists.

pgsql-performance by date:

Previous
From: tsuraan
Date:
Subject: Re: Scaling concerns
Next
From: Greg Smith
Date:
Subject: Re: Scaling concerns