Re: Millisecond-precision connect_timeout for libpq

Поиск
Список
Период
Сортировка
От ivan babrou
Тема Re: Millisecond-precision connect_timeout for libpq
Дата
Msg-id CANWdNRBE9wS2Re6pzkStqOhxNyU+4VSAZUatC1vq+HzTe8grQQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Millisecond-precision connect_timeout for libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Millisecond-precision connect_timeout for libpq  (ivan babrou <ibobrik@gmail.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls