Re: design for parallel backup

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

In response to

Responses

Browse pgsql-hackers by date

  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