Re: Millisecond-precision connect_timeout for libpq - Mailing list pgsql-hackers

From ivan babrou
Subject Re: Millisecond-precision connect_timeout for libpq
Date
Msg-id CANWdNRDaiNo7vgfQFkrMdC4kvmzSdyoBG=Qaj0S4gm_sZeZa2g@mail.gmail.com
Whole thread Raw
In response to Re: Millisecond-precision connect_timeout for libpq  (ivan babrou <ibobrik@gmail.com>)
Responses Re: Millisecond-precision connect_timeout for libpq
List pgsql-hackers
On 5 July 2013 23:47, ivan babrou <ibobrik@gmail.com> wrote:
> On 5 July 2013 23:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ivan babrou <ibobrik@gmail.com> writes:
>>> If you can figure out that postgresql is overloaded then you may
>>> decide what to do faster. In our app we have very strict limit for
>>> connect time to mysql, redis and other services, but postgresql has
>>> minimum of 2 seconds. When processing time for request is under 100ms
>>> on average sub-second timeouts matter.
>>
>> If you are issuing a fresh connection for each sub-100ms query, you're
>> doing it wrong anyway ...
>>
>>                         regards, tom lane
>
> In php you cannot persist connection between requests without worrying
> about transaction state. We don't use postgresql for every sub-100ms
> query because it can block the whole request for 2 seconds. Usually it
> takes 1.5ms to connect, btw.
>
> Can you tell me why having ability to specify more accurate connect
> timeout is a bad idea?
>
> --
> Regards, Ian Babrou
> http://bobrik.name http://twitter.com/ibobrik skype:i.babrou

Nobody answered my question yet.

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



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: psql tab completion for updatable foreign tables
Next
From: "David E. Wheeler"
Date:
Subject: Re: Millisecond-precision connect_timeout for libpq