Re: pg_restore parallel from machine with more CPUs than the server... bad?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




>I have an AWS RDS instance with 4 CPU. I have a EC2 instance I fired up with 16 CPU thinking I could pg_restore --jobs 16 and it would be great, and my restore ground to a halt with a bunch of locks on refreshing materializing views about 600GB into ~700GB.

I am not too sure if it is bad, just that more workers would make use of more resources mem etc :)
Before a restore, I bump maintenance mem etc based resources to speed up building indexes etc.
and then restore it to what it was previously set.
it will still be mostly 4 cpu at work :) doing context switching among 16 workers.

if your db has multiple small objects, parallel restore should be faster than sequential.
If you have many large tables, I am not sure too many workers would be of great help.

as noted in one old thread,
pg14 introduced parallel support for materialised views. till then even with parallelism on, it would only use one worker.

>I was wondering if there was any risk associated with restoring on a computer with more CPU than the destination server (and indeed using more CPU than the server)?
I do not think so. but if this degrades the performance compared with the same setting, then you should come back here to let everyone know the same.

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux