| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: design for parallel backup |
| Date: | 2020-04-22 16:20:52 |
| Message-ID: | 92c77ed1-3540-fefc-62dd-d28402afe954@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2020-04-22 16:21:40 | Re: backup manifests |
| Previous Message | Jehan-Guillaume de Rorthais | 2020-04-22 16:17:17 | Re: [BUG] non archived WAL removed during production crash recovery |