| From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
|---|---|
| To: | Condor <condor(at)stz-bg(dot)com> |
| Cc: | Jerry Sievers <gsievers19(at)comcast(dot)net>, Dorian Hoxha <dorian(dot)hoxha(at)gmail(dot)com>, PostgreSQL <pgsql-general(at)postgresql(dot)org>, pgsql-general-owner(at)postgresql(dot)org |
| Subject: | Re: Uber migrated from Postgres to MySQL |
| Date: | 2016-07-29 20:32:26 |
| Message-ID: | CACjxUsNrqt6-i-GWev5h0h0So52cbdRektSBDZOd_ibq7_0Bcw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Jul 29, 2016 at 3:18 PM, Condor <condor(at)stz-bg(dot)com> wrote:
> On 29-07-2016 20:33, Jerry Sievers wrote:
>> I've done several ~7TB pg_upgrades and with the hard link option and a
>> framework that parallelizes the post-analyzer phase...
>>
>> ...45 minutes till completion.
> GL to you
Luck has nothing to do with anything. You really might want to
post with more details and see whether people can help sort out why
you have seen such slow performance where so many others have not.
I hope it's not just a matter of saying "I have a 1TB database and
upgrade is slow, therefore it is slow because it is 1TB." That
would be roughly the equivalent of saying "I have a blue car and it
is slow, therefore it is slow because it is blue." It just might
be the flat tire that actually matters. If your upgrade is slow
because you have 10 million database objects, that might be a hard
one to overcome, but it might be something with an easy solution in
the pg_upgrade options or server configuration.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2016-07-29 20:37:18 | Re: Allowing multiple versions of PG under NetBSD |
| Previous Message | Larry Rosenman | 2016-07-29 20:22:29 | Re: Allowing multiple versions of PG under NetBSD |