Re: Millisecond-precision connect_timeout for libpq
От | ivan babrou |
---|---|
Тема | Re: Millisecond-precision connect_timeout for libpq |
Дата | |
Msg-id | CANWdNRDaiNo7vgfQFkrMdC4kvmzSdyoBG=Qaj0S4gm_sZeZa2g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Millisecond-precision connect_timeout for libpq (ivan babrou <ibobrik@gmail.com>) |
Ответы |
Re: Millisecond-precision connect_timeout for libpq
|
Список | 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 по дате отправления: