Re: connections

From: "Dave Page" <dpage(at)pgadmin(dot)org>
To: "Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: connections
Date: 2008-04-20 17:00:27
Message-ID: 937d27e10804201000i780a8a55uffcf467319ba7c78@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On Fri, Apr 18, 2008 at 7:30 PM, Roberts, Jon <Jon(dot)Roberts(at)asurion(dot)com> wrote:

> Now my system is actually running Greenplum which means I have 16 more
> (17 total) connections per user's connection because each segment host
> running gets a connection. So my measly 9 users actually are consuming
> 510 database connections!
>
> EnterpriseDB now has a similar product to Greenplum
> http://www.enterprisedb.com/community/projects/gridsql.do and I'm
> assuming it does the same thing. It certainly does look that way based
> on the fact both products make use of parallel execution with shared
> nothing parallel database servers.

I'm awaiting confirmation from the lead architect, but I believe that
a single connection from pgAdmin will result in 1 connection to each
node in the cluster in GridSQL. However I believe there is also a
certain amount of pooling going on so I don't believe it's such a
problem. Besides.... that may be 16 connections in a 16 node system,
but each of those is a complete PostgreSQL/EnterpriseDB server capable
of handling as many connections as it could if it were a standalone
server (which could be hundreds or thousands), so it's no more an
issue than if you had a single server.

> I would greatly prefer if pgAdmin only created a connection if it needed
> to. If a query window is busy and a user attempts to execute SQL while
> the other window is busy, then it would create a new session. A simpler
> solution would be only to allow one connection per pgAdmin instance.

pgAdmin does only create connections when it needs to. The problem
that you're glossing over is determining when a connection is 'idle'
and could be reused. What of temporary tables, or even more basic
things like sequences which can display different characteristics the
first time they're used in a given session compared to subsequent
times?

> Is this even on the radar for EnterpriseDB or pgAdmin users? Is this
> even considered a problem?

No - it's not a problem that I've heard from anyone other than you
(and a few newbies who don't understand why we use multiple
connections), and it's certainly not something the GridSQL guys have
complained about, either internally in EnterpriseDB or out here in
public.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message svn 2008-04-20 17:37:07 SVN Commit by dpage: r7231 - in trunk/pgadmin3: . pgadmin/dlg
Previous Message svn 2008-04-20 16:42:44 SVN Commit by dpage: r7230 - branches/REL-1_8_0_EDB/pgadmin3/pgadmin/frm