Re: Millisecond-precision connect_timeout for libpq
От | ivan babrou |
---|---|
Тема | Re: Millisecond-precision connect_timeout for libpq |
Дата | |
Msg-id | CANWdNRA5wsmvBC=-6BeZnt-zOhHrogdpM97L136omDfWK45o5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Millisecond-precision connect_timeout for libpq (Markus Wanner <markus@bluegap.ch>) |
Список | pgsql-hackers |
On 9 July 2013 12:20, Markus Wanner <markus@bluegap.ch> wrote: > On 07/09/2013 09:15 AM, ivan babrou wrote: >> Database server lost network — boom, 2 seconds delay. What's the point then? > > Oh, I see. Good point. It could still improve connection time during > normal operation, though. Connection time during normal operation is 1.5ms which is fast enough for now. > None the less, I now agree with you: we recommend a pooler, which may be > capable of millisecond timeouts, but arguably is vastly more complex > than the proposed patch. And it even brings its own set of gotchas (lots > of connections). I guess I don't quite buy the complexity argument, yet. Pooler isn't capable of millisecond timeouts. At least I don't see how could I understand that pooler is dead in 50ms. > Sure, gettimeofday() is subject to clock adjustments. But so is time(). > And if you're setting timeouts that low, you probably know what you're > doing (or at least care about latency a lot). Or is gettimeofday() still > considerably slower on certain architectures or in certain scenarios? > Where's the complexity? There's no complexity here :) > Regards > > Markus Wanner -- Regards, Ian Babrou http://bobrik.name http://twitter.com/ibobrik skype:i.babrou
В списке pgsql-hackers по дате отправления: