| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Ants Aasma <ants(at)cybertec(dot)at>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: Further pg_upgrade analysis for many tables |
| Date: | 2012-11-27 00:05:13 |
| Message-ID: | 22186.1353974713@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Testing pg_dump for 4k tables (16 seconds) shows the first row is not
> output by pg_dump until 15 seconds, meaning there can't be any
> parallelism with a pipe. (Test script attached.) Does anyone know how
> to get pg_dump to send some output earlier?
You can't. By the time it knows what order to emit the objects in,
it's done all the preliminary work you're griping about.
(In a dump with data, there would be a meaningful amount of computation
remaining, but not in a schema-only dump.)
> I will now test using PRIMARY KEY and custom dump format with pg_restore
> --jobs to see if I can get parallelism that way.
This seems likely to be a waste of effort for the same reason: you only
get meaningful parallelism when there's a substantial data component to
be restored.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2012-11-27 00:35:03 | Re: Materialized views WIP patch |
| Previous Message | Alvaro Herrera | 2012-11-26 22:59:57 | Re: Failing SSL connection due to weird interaction with openssl |