pg.ddx.io  pgsql-patches@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-patches@postgresql.org
Subject: Re: pg_dump additional options for performance
Date: Sat, 26 Jul 2008 13:56:14 -0400
Message-ID: <24456.1217094974@sss.pgh.pa.us> (raw)
In-Reply-To: <1217091402.3894.1185.camel@ebony.2ndQuadrant>
References: <20080720214335.GB18846@tamriel.snowman.net>
	<1216591180.19656.848.camel@ebony.2ndQuadrant>
	<20080721011829.GC18846@tamriel.snowman.net>
	<20080721014942.GC30869@sonic.net>
	<20080721015850.GD18846@tamriel.snowman.net>
	<18415.1216611275@sss.pgh.pa.us>
	<1216621040.19656.867.camel@ebony.2ndQuadrant>
	<20080721115602.GG18846@tamriel.snowman.net>
	<1216831237.3894.676.camel@ebony.2ndQuadrant>
	<1216832987.3894.678.camel@ebony.2ndQuadrant>
	<20080724032047.GI18846@tamriel.snowman.net>
	<1216885031.3894.739.camel@ebony.2ndQuadrant>
	<21687.1216886041@sss.pgh.pa.us>
	<1216889809.3894.747.camel@ebony.2ndQuadrant>
	<2818.1217027784@sss.pgh.pa.us>
	<1217063104.3894.1100.camel@ebony.2ndQuadrant>
	<23540.1217089204@sss.pgh.pa.us>
	<1217091402.3894.1185.camel@ebony.2ndQuadrant>

Simon Riggs <simon@2ndquadrant.com> writes:
> I want to dump tables separately for performance reasons. There are
> documented tests showing 100% gains using this method. There is no gain
> adding this to pg_restore. There is a gain to be had - parallelising
> index creation, but this patch doesn't provide parallelisation.

Right, but the parallelization is going to happen sometime, and it is
going to happen in the context of pg_restore.  So I think it's pretty
silly to argue that no one will ever want this feature to work in
pg_restore.

To extend the example I just gave to Stephen, I think a fairly probable
scenario is where you only need to tweak some "before" object
definitions, and then you could do

pg_restore --schema-before-data whole.dump >before.sql
edit before.sql
psql -f before.sql target_db
pg_restore --data-only --schema-after-data -d target_db whole.dump

which (given a parallelizing pg_restore) would do all the time-consuming
steps in a fully parallelized fashion.

			regards, tom lane



view thread (54+ messages)  latest in thread

Message-ID: <24456.1217094974@sss.pgh.pa.us>
Permalink:  ../24456.1217094974@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/24456.1217094974@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-patches@postgresql.org
  Cc: tgl@sss.pgh.pa.us, simon@2ndquadrant.com, sfrost@snowman.net
  Subject: Re: pg_dump additional options for performance
  In-Reply-To: <24456.1217094974@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox