On Thu, Aug 29, 2013 at 6:14 AM, bsreejithin <bsreejithin@xxxxxxxxx> wrote: > > I am *expecting 1000+ hits to my PostgreSQL DB* and I doubt my standalone DB > will be able to handle it. > > So I want to *scale out by adding more servers to share the load*. For this, > I want to do clustering. > > I am *curious to know how clustering works in PostgreSQL.* (I don't want to > know how to setup cluster - as of now. Just want to know how clustering > works). > > When I look at some of the content available while googling, I am getting > more and more confused, as I find that in most of the sites, clustering is > used interchangeably with replication. > > *My purpose is scale out to handle more load, not high availability.* > > Can any one please help me with the details or guide me to use urls. What you are doing is called capacity planning, and it's a vital step before deploying an app and the servers to support it. Look at several things: How many WRITEs do you need to make a second. How many READs do you need to make a second. How big will your data set be. How many clients you'll have concurrently. Your first post pretty much just has how many concurrent users. Later posts had read and writes but didn't specify if that's per user or in total. I'm guessing per user. Either way the total load you listed was pretty small. So yeah, the pgbouncer pooling solution looks optimal. But you might want to look at how big your data set is, how fast it will grow, and what kind of indexes it'll need for good performance as well. If your data set is likely to get REALLY big then that's another issue to tackle as well. To understand recursion, one must first understand recursion. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
