David Kerr <dmk@xxxxxxxxxxxxxx> wrote: > My assertian/hope is that the saturation point > on this machine should be higher than most. Here's another way to think about it -- how long do you expect your average database request to run? (Our top 20 transaction functions average about 3ms per execution.) What does that work out to in transactions per second? That's the TPS you can achieve *on each connection* if your pooler is efficient. If you've determined a connection pool size based on hardware resources, divide your anticipated requests per second by that pool size. If the result is less than the TPS each connection can handle, you're in good shape. If it's higher, you may need more hardware to satisfy the load. Of course, the only way to really know some of these numbers is to test your actual application on the real hardware under realistic load; but sometimes you can get a reasonable approximation from early tests or "gut feel" based on experience with similar applications. I strongly recommend trying incremental changes to various configuration parameters once you have real load, and monitor the impact. The optimal settings are often not what you expect. And if the pooling isn't producing the results you expect, you should look at its configuration, or (if you can) try other pooler products. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
