Ivan Voras <ivoras@xxxxxxxxxxx> wrote: > On 11/22/10 02:47, Kevin Grittner wrote: >> Ivan Voras wrote: >> >>> After 16 clients (which is still good since there are only 12 >>> "real" cores in the system), the performance drops sharply >> >> Yet another data point to confirm the importance of connection >> pooling. :-) > > I agree, connection pooling will get rid of the symptom. But not > the underlying problem. I'm not saying that having 1000s of > connections to the database is a particularly good design, only > that there shouldn't be a sharp decline in performance when it > does happen. Ideally, the performance should remain the same as it > was at its peek. Well, I suggested that we add an admission control[1] mechanism, with at least part of the initial default policy being that there is a limit on the number of active database transactions. Such a policy would do what you are suggesting, but the idea was shot down on the basis that in most of the cases where this would help, people would be better served by using an external connection pool. If interested, search the archives for details of the discussion. -Kevin [1] http://db.cs.berkeley.edu/papers/fntdb07-architecture.pdf Joseph M. Hellerstein, Michael Stonebraker and James Hamilton. 2007. Architecture of a Database System. Foundations and Trends(R) in Databases Vol. 1, No. 2 (2007) 141*259 (see Section 2.4 - Admission Control) -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
