Re: Any better plan for this query?..

On Tue, May 12, 2009 at 8:59 AM, Dimitri <dimitrik(dot)fr(at)gmail(dot)com> 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