Re: Millisecond-precision connect_timeout for libpq

On Jul 8, 2013, at 1:31 PM, ivan babrou <ibobrik(at)gmail(dot)com> wrote:
> On 8 July 2013 20:40, David E. Wheeler <david(at)justatheory(dot)com> wrote:
>> On Jul 8, 2013, at 7:44 AM, ivan babrou <ibobrik(at)gmail(dot)com> wrote:
>>
>>>> Can you tell me why having ability to specify more accurate connect
>>>> timeout is a bad idea?
>>>
>>> Nobody answered my question yet.
>>
>> From an earlier post by Tom:
>>
>>> What exactly is the use case for that? It seems like extra complication
>>> for something with little if any real-world usefulness.
>>
>> So the answer is: extra complication.
>>
>> Best,
>>
>> David
>
> I don't see any extra complication in backwards-compatible patch that
> removes more lines that adds. Can you tell me, what exactly is extra
> complicated?
>
> About pooling connections: we have 150 applications servers and 10
> postgresql servers. Each app connects to each server -> 150
> connections per server if I run pooler on each application server.
> That's more than default setting and now we usually have not more than
> 10 connections per server. What would happen if we have 300 app
> servers? I thought connections consume some memory. Running pooler not
> on every app server gives no advantage — I still may get network
> blackhole and 2 seconds delay. Moreover, now I can guess that
> postgresql is overloaded if it does not accept connections, with
> pooler I can simply blow up disks with heavy io.
>
> Seriously, I don't get why running 150 poolers is easier. And my
> problem is still here: server (pooler is this case) is down — 2
> seconds delay. 2000% slower.
>
> Where am I wrong?

I agree with you.

...Robert