| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Make deparsing of column defaults faster |
| Date: | 2018-07-06 20:47:15 |
| Message-ID: | 53e9c6cc-460c-756e-e619-a4dcedd6f3d7@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 05.07.18 18:58, Justin Pryzby wrote:
> I checked on one customer running PG10.4, for which pg_dump takes 8 minutes to
> pg_dump -s.
>
> I imported existing schema to PG12dev (which itself took 25min) and compared:
> patched: 2m33.616s
> unpatched: 7m19.578s
Which patch is that, Jeff's or mine?
> Note, that affects pg_upgrade, which is how this issue originally came up [0].
> (But I believe pg_upgrade likes to call pg_dump from the old server version, so
> pg_upgrade to v11 couldn't benefit unless this was included in PG10.5).
pg_upgrade calls the new pg_dump.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-07-06 20:52:14 | Re: [PATCH] Use access() to check file existence in GetNewRelFileNode(). |
| Previous Message | Tom Lane | 2018-07-06 20:10:38 | Re: "interesting" issue with restore from a pg_dump with a database-wide search_path |