Re: pg_dump additional options for performance - Mailing list pgsql-patches

From Tom Lane
Subject Re: pg_dump additional options for performance
Date
Msg-id 3677.1217690641@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump additional options for performance  (chris <cbbrowne@ca.afilias.info>)
List pgsql-patches
chris <cbbrowne@ca.afilias.info> writes:
> Do we need to wait until a fully-parallelizing pg_restore is
> implemented before adding this functionality to pg_dump?

They're independent problems ... and I would venture that parallel
dump is harder.

> Further, it's actually not obvious that we *necessarily* care about
> parallelizing loading data.  The thing that happens every day is
> backups.

Maybe so, but I would say that routine backups shouldn't be designed
to eat 100% of your disk bandwidth anyway --- they'd be more like
background tasks.

            regards, tom lane

pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS]odd output in restore mode
Next
From: Simon Riggs
Date:
Subject: Re: WIP: Transportable Optimizer Mode