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
|
Список | 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 по дате отправления: