Simon Riggs <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
