At 22:59 9/07/00 -0400, Tom Lane wrote:
>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 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.
>
You could pre-start servers (ala Apache), then when a connection request
comes in, the connection should be pretty fast. This would involve
defining, for each database, the number of servers to prestart (default 0),
and perhaps the minimum number of free servers to maintain (ie. when all
free servers are used up, automatically create some new ones). You would
definitely need to make this dynamic to allow for clean database shutdowns.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
