Roberts, Jon wrote:
> 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.
And would make pgAdmin more or less useless for most people.
> 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.
Well, like I said I can't imagine you actually saving any significant
amount of connections using a pool anyway. We already reuse the
maintenance DB connection when browsing that database, and connections
to other databases are only created when required by a user action (and
don't forget of course, a connection is fundamentally tied to one
database in postgres so you can't reuse the maintenance DB connection
for some other database). Other connections are used by tools like the
status monitor, query tool and data editor, but as Heikki pointed out,
we have good reason for wanting to keep those seperate from one another.
If the fact that GP creates a connection to each node for each user
connection is such a resource issue for you, I would suggest petitioning
them to implement a lightweight protocol for inter-node communication.
Regards, Dave.