From: | John R Pierce <pierce(at)hogranch(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Uber migrated from Postgres to MySQL |
Date: | 2016-07-28 22:26:17 |
Message-ID: | e13eae5b-1084-5dcf-31dc-f61f52dbee52@hogranch.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)hogranch(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-07-28 22:53:58 | Re: Uber migrated from Postgres to MySQL |
Previous Message | Bruce Momjian | 2016-07-28 22:16:48 | Re: Uber migrated from Postgres to MySQL |