Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> I'm wondering about the comments that postgres is slower in connection
> time, could this be related to that libpq always uses asynchronous
> sockets to connect? It always turns off blocking and then goes through a
> state machine to go through the various stages of connect, instead of
> just calling connect() and waiting for the kernel to do its thing.
I think you'd be wasting your time to "improve" that. A couple of
kernel calls are not enough to explain the problem. Moreover, we
had complaints about slow startup even back when libpq had never heard
of async anything.
I believe that the problem is on the backend side: there's an awful lot
of cache-initialization and so forth that happens each time a backend
is started. It's quick enough to be hard to profile accurately,
however, so getting the info needed to speed it up is not so easy.
regards, tom lane