| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
| Subject: | Re: Further pg_upgrade analysis for many tables |
| Date: | 2012-11-10 17:18:11 |
| Message-ID: | 20121110171811.GC31383@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 9, 2012 at 04:23:40PM -0800, Jeff Janes wrote:
> > Actually, pg_upgrade needs pg_dump to restore all those sequence values.
>
> I did an experiment where I had pg_dump just output dummy values
> rather than hitting the database. Once pg_upgrade moves the relation
> files over, the dummy values disappear and are set back to their
> originals. So I think that pg_upgrade depends on pg_dump only in a
> trivial way--they need to be there, but it doesn't matter what they
> are.
FYI, thanks everyone for testing this. I will keep going on my tests
--- seems I have even more things to try in my benchmarks. I will
publish my results soon.
In general, I think we are getting some complaints about dump/restore
performance with a large number of tables, irregardless of pg_upgrade,
so it seems worthwhile to try to find the cause.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-11-10 17:41:27 | Re: Inadequate thought about buffer locking during hot standby replay |
| Previous Message | Ants Aasma | 2012-11-10 17:17:34 | Re: Further pg_upgrade analysis for many tables |