Re: Uber migrated from Postgres to MySQL
| От | John R Pierce |
|---|---|
| Тема | Re: Uber migrated from Postgres to MySQL |
| Дата | |
| Msg-id | e13eae5b-1084-5dcf-31dc-f61f52dbee52@hogranch.com обсуждение исходный текст |
| Ответ на | Re: Uber migrated from Postgres to MySQL (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: Uber migrated from Postgres to MySQL
|
| Список | pgsql-general |
On 7/28/2016 3:16 PM, Bruce Momjian wrote:
On Thu, Jul 28, 2016 at 12:35:23AM -0700, Jeff Janes wrote:> On Wed, Jul 27, 2016 at 9:48 PM, John R Pierce <pierce@hogranch.com> wrote:> > On 7/27/2016 9:39 PM, Jeff Janes wrote:> >> > >> That depends on how how many objects there are consuming that 1 TB. > >> With millions of small objects, you will have problems. Not as many > >> in 9.5 as there were in 9.1, but still it does not scale linearly in > >> the number of objects. If you only have thousands of objects, then as > >> far as I know -k works like a charm.> > > > > > millions of tables?> > Well, it was a problem at much smaller values, until we fixed many of > them. But the perversity is, if you are stuck on a version before the > fixes, the problems prevent you from getting to a version on which it > is not a problem any more.Uh, that is only true if the slowness was in _dumping_ many objects. Most of the fixes have been for _restoring_ many objects, and that is done in the new cluster, so they should be OK.
I thought we were talking about pg_upgrade in -k link mode? or does that rely on a dump/restore --schema-only operation to create the metadata?
-- john r pierce, recycling bits in santa cruz
В списке pgsql-general по дате отправления: