Re: [External] Re: Import Database

From: Vijaykumar Jain <vjain(at)opentable(dot)com>
To: Ravi Krishna <ravi_krishna(at)aol(dot)com>
Cc: Sathish Kumar <satcse88(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org >> PG-General Mailing List" <pgsql-general(at)postgresql(dot)org>
Subject: Re: [External] Re: Import Database
Date: 2019-05-05 17:32:18
Message-ID: CAE7uO5g46f+VVfbxXRuBSA2kYcakr+QLr6YhvuM+ATT7GXMRpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Yes.
I do bump up maintenance_work_mem temporarily during a restore.
it helps in rebuilding on indexes a little faster.
Turning fsync off during restore will help the restore a little fast too
but in case of any crash you may have to restart the restore from scratch.
Also do have the option to take pg_dump and run pg_restore ? or you just
the have the raw sql dump to work with?
if you have the option of taking a dump again, you can try using pg_dump
and pg_restore with -Fc (custom format) and -j n (parallel) option along
with temp bump in maint memory.
This will make the restore a little faster that raw sql dump I think.
If you are on pg10 or above? you can use logical replication to mirror the
database.
There are blogs by several people explaining how to do that, that may be
helpful.

On Sun, 5 May 2019 at 10:29 PM Ravi Krishna <ravi_krishna(at)aol(dot)com> wrote:

> IMO you are using the slowest tool to import.
>
> Just one quick question: Why can't you take cluster backup using any of
> the tools available and then drop all
> unwanted databases after you import the cluster.
>
> pg_basebackup will do a good job.
>
> --

Regards,
Vijay

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sathish Kumar 2019-05-05 23:14:27 Re: [External] Re: Import Database
Previous Message Ron 2019-05-05 17:26:28 Re: Import Database