Re: pg_dump additional options for performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
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 18:18:04
Message-ID: 5513.1204049884@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> I've not been advocating improving pg_restore, which is where the -Fc
> tricks come in.
> ...
> 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.

OK, the reason I didn't grasp what you are proposing is that it's insane.

We can easily, and backwards-compatibly, improve pg_restore to do
concurrent restores. Trying to make psql do something like this will
require a complete rewrite, and there is no prospect that it will work
for any input that didn't come from (an updated version of) pg_dump
anyway. Furthermore you will have to write a whole bunch of new code
just to duplicate what pg_dump/pg_restore already do, ie store/retrieve
the TOC and dependency info in a program-readable fashion.

Since the performance advantages are still somewhat hypothetical,
I think we should reach for the low-hanging fruit first. If concurrent
pg_restore really does prove to be the best thing since sliced bread,
*then* would be the time to start thinking about whether it's possible
to do the same thing in less-constrained scenarios.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-02-26 18:29:39 Re: pg_dump additional options for performance
Previous Message Simon Riggs 2008-02-26 18:13:21 Re: pg_dump additional options for performance