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
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 |