Re: pg_dump additional options for performance

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump additional options for performance
Date: 2008-02-26 17:16:51
Message-ID: 1204046211.4252.363.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2008-02-26 at 10:48 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > My thinking is to do either:
> > * keep it as simple as possible to allow DBA to manually improve
> > performance
> > * express dependency information in the pg_dump output to allow some
> > level of parallelism to use that information to advantage automatically
>
> I'm astonished at how much pontificating is going on in this thread
> from people who seem unaware of what pg_dump *already* does.
>
> If you don't already know exactly what is in an -Fc dump, you are
> unqualified to be discussing how to improve it.

I've not been advocating improving pg_restore, which is where the -Fc
tricks come in.

pg_dump can write text files that can be input to psql. pg_dump already
has the dependency information *but* it doesn't write the dependency
info to a psql-able file. But it could, which is what I meant.

If we created a grammar for psql that allowed dependency information to
be expressed then pg_dump and pg_restore could generate scripts with
their dependency info expressed in the psql grammar.

I see you thought I meant pg_restore. I don't thinking extending
pg_restore in that way is of sufficiently generic use to make it
worthwhile. Extending psql would be worth it, since not all psql scripts
come from pg_dump.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2008-02-26 17:19:48 Varlena Type Creation
Previous Message Alvaro Herrera 2008-02-26 17:04:54 Re: Including PL/PgSQL by default