| From: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
|---|---|
| To: | Durgamahesh Manne <maheshpostgres9(at)gmail(dot)com> |
| Cc: | PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Regarding db dump with Fc taking very long time to completion |
| Date: | 2019-08-30 10:41:24 |
| Message-ID: | CAKoxK+504bWyW_CnJ_vdyfMAgSstHVtPQvnB0oMnE9nVjaLn8w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Aug 30, 2019 at 11:51 AM Durgamahesh Manne
<maheshpostgres9(at)gmail(dot)com> wrote:
> Logical dump of that table is taking more than 7 hours to be completed
>
> I need to reduce to dump time of that table that has 88GB in size
Good luck!
I would see two possible solutions to the problem:
1) use physical backup and switch to incremental (e..g, pgbackrest)
2) partition the table and backup single pieces, if possible
(constraints?) and be assured it will become hard to maintain (added
partitions, and so on).
Are all of the 88 GB be written during a bulk process? I guess no, so
maybe partitioning you can avoid locking the whole dataset and reduce
contention (and thus time).
Luca
| From | Date | Subject | |
|---|---|---|---|
| Next Message | stan | 2019-08-30 10:48:01 | "storing" a calculated value in plsql function ? |
| Previous Message | Durgamahesh Manne | 2019-08-30 09:51:36 | Regarding db dump with Fc taking very long time to completion |