On Tue, May 12, 2009 at 11:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Matthew Wakeling <matthew@flymine.org> writes:
>> On Tue, 12 May 2009, Simon Riggs wrote:
>>> No, we spawn then authenticate.
>
>> But you still have a single thread doing the accept() and spawn. At some
>> point (maybe not now, but in the future) this could become a bottleneck
>> given very short-lived connections.
>
> More to the point, each backend process is a pretty heavyweight object:
> it is a process, not a thread, and it's not going to be good for much
> until it's built up a reasonable amount of stuff in its private caches.
> I don't think the small number of cycles executed in the postmaster
> process amount to anything at all compared to the other overhead
> involved in getting a backend going.
AIUI, whenever the connection pooler switches to serving a new client,
it tells the PG backend to DISCARD ALL. But why couldn't we just
implement this same logic internally? IOW, when a client disconnects,
instead of having the backend exit immediately, have it perform the
equivalent of DISCARD ALL and then stick around for a minute or two
and, if a new connection request arrives within that time, have the
old backend handle the new connection...
(There is the problem of how to get the file descriptor returned by
the accept() call in the parent process down to the child... but I
think that at least on some UNIXen there is a way to pass an fd
through a socket, or even dup it into another process by opening it
from /proc/fd)
...Robert