On 2013-08-22 07:39:41 +0200, PostgreSQL - Hans-Jürgen Schönig wrote: > >> regarding the client side implementation: we have chosen this way because > >> it is less invasive. > >> i cannot see a reason to do this on the server side because we won't have > >> 10 > >> pg_basebackup-style tools making use of this feature anyway. > > > > The problem is that receiver side throttling over TCP doesn't always > > work all that nicely unless you have a low rate of transfer and/or very > > low latency . Quite often you will have OS buffers/the TCP Window being > > filled in bursts where the sender sends at max capacity and then a > > period where nothing happens on the sender. That's often not what you > > want when you need to throttle. > > > > Besides, I can see some value in e.g. normal streaming replication also > > being rate limited... > > > > > what would be a reasonable scenario where limiting streaming would make > sense? i cannot think of any to be honest.
It's not an unreasonable goal if you have several streaming replicas with only some of them being synchronous replicas. Also, analytics replicas that need to catchup don't really need priority over local operations. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
