Skip site navigation (1) Skip section navigation (2)

Re: Peformance Tuning Opterons/ Hard Disk Layout

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruno Almeida do Lago <teolupus(at)gmail(dot)com>,'Michael Adler' <adler(at)pobox(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Peformance Tuning Opterons/ Hard Disk Layout
Date: 2005-02-25 16:20:05
Message-ID: (view raw or whole thread)
Lists: pgsql-performance
On Wed, Feb 23, 2005 at 01:37:28PM -0500, Tom Lane wrote:
> "Bruno Almeida do Lago" <teolupus(at)gmail(dot)com> writes:
> > Is there a real limit for max_connections? Here we've an Oracle server with
> > up to 1200 simultaneous conections over it!
> [ shrug... ] If your machine has the beef to run 1200 simultaneous
> queries, you can set max_connections to 1200.
> The point of what you were quoting is that if you want to service
> 1200 concurrent users but you only expect maybe 100 simultaneously
> active queries from them (and you have a database box that can only
> service that many) then you want to put a connection pooler in
> front of 100 backends, not try to start a backend for every user.
> Oracle may handle this sort of thing differently, I dunno.
> 			regards, tom lane

Oracle has some form of built-in connection pooling. I don't remember
the exact details of it off the top of my head, but I think it was a
'wedge' that clients would connect to as if it was the database, and the
wedge would then find an available database process to use.
Jim C. Nasby, Database Consultant               decibel(at)decibel(dot)org 
Give your computer some brain candy! Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

In response to

pgsql-performance by date

Next:From: Markus SchaberDate: 2005-02-25 16:28:58
Subject: Re: is pg_autovacuum so effective ?
Previous:From: Tom LaneDate: 2005-02-25 16:05:10
Subject: Re: Possible interesting extra information for explain analyze?

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group