>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.
