Re: Uber migrated from Postgres to MySQL - Mailing list pgsql-general

From John R Pierce
Subject Re: Uber migrated from Postgres to MySQL
Date
Msg-id e13eae5b-1084-5dcf-31dc-f61f52dbee52@hogranch.com
Whole thread Raw
In response to Re: Uber migrated from Postgres to MySQL  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Uber migrated from Postgres to MySQL  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Uber migrated from Postgres to MySQL
Next
From: Bruce Momjian
Date:
Subject: Re: Uber migrated from Postgres to MySQL