On Tue, May 12, 2009 at 8:59 AM, Dimitri <dimitrik.fr@xxxxxxxxx> wrote: > Wait wait, currently I'm playing the "stress scenario", so there are > only 256 sessions max, but thing time is zero (full stress). Scenario > with 1600 users is to test how database is solid just to keep a huge > amount of users, but doing only one transaction per second (very low > global TPS comparing to what database is able to do, but it's testing > how well its internals working to manage the user sessions). Didn't we beat this to death in mid-March on this very same list? Last time I think it was Jignesh Shah. AIUI, it's a well-known fact that PostgreSQL doesn't do very well at this kind of workload unless you use a connection pooler. *goes and checks the archives* Sure enough, 116 emails under the subject line "Proposal of tunable fix for scalability of 8.4". So, if your goal is to find a scenario under which PostgreSQL performs as badly as possible, congratulations - you've discovered the same case that we already knew about. Obviously it would be nice to improve it, but IIRC so far no one has had any very good ideas on how to do that. If this example mimics a real-world workload that you care about, and if using a connection pooler is just not a realistic option in that scenario for whatever reason, then you'd be better off working on how to fix it than on measuring it, because it seems to me we already know it's got problems, per previous discussions. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
