From: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Greg Smith <gsmith(at)gregsmith(dot)com>, James Mansion <james(at)mansionfamily(dot)plus(dot)com>, Flavio Henrique Araque Gurgel <flavio(at)4linux(dot)com(dot)br>, Fabrix <fabrixio1(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Scalability in postgres |
Date: | 2009-06-03 17:26:56 |
Message-ID: | 5482c80a0906031026ta5eb813kd35a0811e5867b19@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Few weeks ago tested a customer application on 16 cores with Oracle:
- 20,000 sessions in total
- 70,000 queries/sec
without any problem on a mid-range Sun box + Solaris 10..
Rgds,
-Dimitri
On 6/3/09, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> James Mansion <james(at)mansionfamily(dot)plus(dot)com> wrote:
>
>> I'm sure most of us evaluating Postgres from a background in Sybase
>> or SQLServer would regard 5000 connections as no big deal.
>
> Sure, but the architecture of those products is based around all the
> work being done by "engines" which try to establish affinity to
> different CPUs, and loop through the various tasks to be done. You
> don't get a context switch storm because you normally have the number
> of engines set at or below the number of CPUs. The down side is that
> they spend a lot of time spinning around queue access to see if
> anything has become available to do -- which causes them not to play
> nice with other processes on the same box.
>
> If you do connection pooling and queue requests, you get the best of
> both worlds. If that could be built into PostgreSQL, it would
> probably reduce the number of posts requesting support for bad
> configurations, and help with benchmarks which don't use proper
> connection pooling for the product; but it would actually not add any
> capability which isn't there if you do your homework....
>
> -Kevin
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-06-03 17:45:31 | Re: Scalability in postgres |
Previous Message | Scott Carey | 2009-06-03 17:08:23 | Re: poor performing plan from analyze vs. fast default plan pre-analyze on new database |