Re: Number of connections

> -----Original Message-----
> From: Dave Page [mailto:dpage(at)postgresql(dot)org]
> Sent: Monday, December 10, 2007 9:42 AM
> To: Roberts, Jon
> Cc: pgadmin-hackers
> Subject: Re: [pgadmin-hackers] Number of connections
>
> Roberts, Jon wrote:
> > I would think far less code would be needed if the tool could be
> configured
> > to only use one connection.
>
> How'd you figure that? You'd need to write the connection pooler, start
> tracking connection states in far more detail than we do now, and
> potentially have to start new connections (which is expensive) in
> response to UI interactions which the user may well expect to be almost
> instantaneous.
>
> More importantly, I don't imagine you'd save much anyway - connections
> are relatively cheap, and pgAdmin only creates them when you actually
> need them (and closes them when you close Windows for which they were
> created). I can't imagine such an architecture saving more than 1 in ten
> connections at best.
>

I mean this:
Solution 1: Manage a complicated connection pool like you described above.
Solution 2: Only allow one connection to the database. A new query window
will not create a new connection. The tool will not allow new queries to
execute while another query is executing.

The second solution would require less code than the first one.

Additionally, this second solution could be a preference setting:
"Multithreaded Yes/No"

The reason I'm bringing this up is because it is a big deal to manage all of
the connections when using Greenplum. Each connection really means a
connection to each internal database. There is one database per CPU core
plus the master node. For us, that means we have 17 connections per user's
connection. When there are three connections needed for a single query to
run, it really means there are 51 connections total connections to all of
the underlying databases.

Jon