Re: Millisecond-precision connect_timeout for libpq

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?

--
Regards, Ian Babrou
http://bobrik.name http://twitter.com/ibobrik skype:i.babrou