Re: Connection Pooling, a year later

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: owensmk(at)earthlink(dot)net
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Connection Pooling, a year later
Date: 2001-12-18 01:16:59
Message-ID: 8892.1008638219@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Owens <owensmk(at)earthlink(dot)net> writes:
> Even if the descriptor passing were not the best (most portable) way to get
> information from the client - postmaster to the backend, there still might be
> another way by which data from the client socket can be transmitted to a
> backend, thereby allowing the data from multiple clients to be sent to a
> single backend. For instance, the postmaster could accept() and also
> multiplex (select()/poll(), or use kqueue on BSD) across all file
> descriptors, sending and receiving data to/from the clients.

That would turn the postmaster into a performance bottleneck, since it
would have to do work for every client interaction.

Another objection is that the postmaster would need to have two open
file descriptors (the original client connection and a pipe to the
backend) for every active connection. On systems with a fairly low
max-files-per-process setting (~ 50 is not uncommon) that would put
a serious crimp in the number of connections that could be supported.

On the whole it strikes me as more practical to do connection pooling
on the client side...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2001-12-18 02:34:25 Re: Connection Pooling, a year later
Previous Message Michael Owens 2001-12-18 00:46:44 Connection Pooling, a year later