It's not that trivial with Oracle either. I guess you had to use shared servers to get to that amount of sessions. They're most of the time not activated by default (dispatchers is at 0). Granted, they are part of the 'main' product, so you just have to set up dispatchers, shared servers, circuits, etc ... but there is still setup to do : dispatchers are (if I recall correctly) a completely manual parameter (and every dispatcher can only drive a certain amount of sessions, dependant on the operating system), where shared servers is a bit more dynamic, but still uses processes (so you may have to tweak max processes also). What I mean to say is that Oracle does something quite alike PostgreSQL + a connection pooler, even if it's more advanced (it's a shared memory structure that is used to send messages between dispatchers and shared servers). Or did you mean that you had thousands of sessions in dedicated mode ? On Wednesday 03 June 2009 20:13:39 Dimitri wrote: > Just to say you don't need a mega server to keep thousands connections > with Oracle, it's just trivial, nor CPU affinity and other stuff you > may or may not need with Sybase :-) > > Regarding PostgreSQL, I think it'll only benefit to have an integrated > connection pooler as it'll make happy all populations anyway: > - those who don't like the idea may always disable it :-) > - those who have a lot but mostly inactive sessions will be happy to > simplify session pooling > - those who really seeking for the most optimal workload on their > servers will be happy twice: if there are any PG scalability limits, > integrated pooler will be in most cases more performant than external; > if there are no PG scalability limits - it'll still help to size PG > most optimally according a HW or OS capacities.. > > Rgds, > -Dimitri > > On 6/3/09, Kevin Grittner <Kevin.Grittner@xxxxxxxxxxxx> wrote: > > Dimitri <dimitrik.fr@xxxxxxxxx> wrote: > >> 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.. > > > > I'm not sure what point you are trying to make. Could you elaborate? > > > > (If it's that Oracle doesn't need an external connection pool, then > > are you advocating that PostgreSQL include that in the base product?) > > > > -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
