Re: design for parallel backup - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: design for parallel backup
Date
Msg-id 92c77ed1-3540-fefc-62dd-d28402afe954@2ndquadrant.com
Whole thread Raw
In response to Re: design for parallel backup  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: design for parallel backup  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2020-04-20 22:36, Robert Haas wrote:
> My suspicion is that it has mostly to do with adequately utilizing the
> hardware resources on the server side. If you are network-constrained,
> adding more connections won't help, unless there's something shaping
> the traffic which can be gamed by having multiple connections.

This is a thing.  See "long fat network" and "bandwidth-delay product" 
(https://en.wikipedia.org/wiki/Bandwidth-delay_product).  The proper way 
to address this is presumably with TCP parameter tuning, but in practice 
it's often easier to just start multiple connections, for example, when 
doing a backup via rsync.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: design for parallel backup
Next
From: Fujii Masao
Date:
Subject: Re: backup manifests