Re: design for parallel backup

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: design for parallel backup
Date: 2020-04-21 15:36:02
Message-ID: 20200421153602.z6de5ixate5hp5j4@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-04-21 07:18:20 -0400, Robert Haas wrote:
> On Tue, Apr 21, 2020 at 2:44 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > FWIW, I just tested pg_basebackup locally.
> >
> > Without compression and a stock postgres I get:
> > unix tcp tcp+ssl:
> > 1.74GiB/s 1.02GiB/s 699MiB/s
> >
> > That turns out to be bottlenecked by the backup manifest generation.
>
> Whoa. That's unexpected, at least for me. Is that because of the
> CRC-32C overhead, or something else? What do you get with
> --manifest-checksums=none?

It's all CRC overhead. I don't see a difference with
--manifest-checksums=none anymore. We really should look for a better
"fast" checksum.

Regards,

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-04-21 15:45:53 Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables
Previous Message Alvaro Herrera 2020-04-21 15:34:54 Re: More efficient RI checks - take 2