From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Léo FERLIN SUTTON <lferlin(at)mailjet(dot)com> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Slow pg_dump affecting pg_upgrade speed |
Date: | 2018-01-04 17:53:42 |
Message-ID: | 20180104175342.GA5478@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, Dec 12, 2017 at 02:24:54PM +0100, Léo FERLIN SUTTON wrote:
> We believe this is related to the size of our pg_catalog, we have
> thousands (if not hundred of thousands of views) on most of our
> databases. Here is an example on cluster A :
...
> We are completely aware that this is a *bad* idea, and our newer
I appreciate your candor. :-)
> developments are all moving far far away for this type of schema,
> however we are currently stuck with this for at least a few more
> months if not years.
>
> My question to this mailing list is : Are we missing something that
> could speed up the pg_dump ?
There isn't much we can do to speed it up anymore. We optimized the
schema restore in the past, at least with the ideas we had. A new idea
we discussed last month was to allow the schema dump/restore while the
old server is running. You can see the discussion here:
That is only brainstorming at this point and it is not clear we will
even implement it.
The bottom line is that pg_upgrade is much more effective on large
databases with a smaller number of database objects than the reverse.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Francis Santiago | 2018-01-04 17:58:48 | Re: Production Database requirement |
Previous Message | Azimuddin Mohammed | 2018-01-04 17:47:41 | Production Database requirement |