L
> On Dec 4, 2018, at 11:13 PM, Rene Romero Benavides
> wrote:
>
> I tend to believe that a backup (pg_dump) in custom format (-F c) using
> multiple jobs (parallel) -> restore (pg_restore) also with multiple
> concurrent jobs would be better.
>
>> Am Di., 4. Dez. 2018 um 21:14 Uhr schrieb
pg_backup/pg_restore will work, but parallel is pointless on a single
(unpartitioned) table.
On 12/05/2018 12:13 AM, Rene Romero Benavides wrote:
I tend to believe that a backup (pg_dump) in custom format (-F c) using
multiple jobs (parallel) -> restore (pg_restore) also with multiple
concurre
On 12/04/2018 09:14 PM, Rhys A.D. Stewart wrote:
Greetings Folks,
I have a relatively large table (100m rows) that I want to move to a
new box with more resources. The table isn't doing anything...i.e its
not being updated or read from. Which approach would be faster to move
the data over:
a
On 12/05/2018 12:05 AM, Rob Sargent wrote:
On Dec 4, 2018, at 8:14 PM, Rhys A.D. Stewart wrote:
Greetings Folks,
I have a relatively large table (100m rows) that I want to move to a
new box with more resources. The table isn't doing anything...i.e its
not being updated or read from. Which appr
I tend to believe that a backup (pg_dump) in custom format (-F c) using
multiple jobs (parallel) -> restore (pg_restore) also with multiple
concurrent jobs would be better.
Am Di., 4. Dez. 2018 um 21:14 Uhr schrieb Rhys A.D. Stewart <
rhys.stew...@gmail.com>:
> Greetings Folks,
>
> I have a relat
> On Dec 4, 2018, at 8:14 PM, Rhys A.D. Stewart wrote:
>
> Greetings Folks,
>
> I have a relatively large table (100m rows) that I want to move to a
> new box with more resources. The table isn't doing anything...i.e its
> not being updated or read from. Which approach would be faster to move
