Standard queues provide at-least-once delivery, which means that each message is delivered at least once. FIFO queues provide exactly-once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue.

..so I guess that you mean standard queue with several worker processes dequeuing items from the queue. In this case the CPU utilization would likely depend on the number of workers, wouldn't it?
 

I guess it would not as ZRemove / ZLoad / ZIinsert / ZSave commands are mostly used as tools for the legacy way of editing routines (using routine buffer) rather than for code execution. Of course, one can execute the code inside the previously loaded routine: `zload routine do sub(...)`, but this looks strange if compared with the normal way of doing the same using `do sub^routine(...)` or `set sc=$$fun^routine(...)`. In short, virtually nobody runs code this way.

Hello Stefan,

Thanks for the reference, while I'm still not sure about the step #2 as ^JRNRESTO provides the  (defaulted) option to disable journaling of updates during the restore to make the operation faster, see the step #10 of Restore Globals From Journal Files Using ^JRNRESTO. Besides, this is the only option compatible with parallel dejournaling. So the idea to switch off journaling system-wide looks excessive.

Regards,
Alexey

The manual says I should (in short):

  1. Stop journaling with ^JRNSTOP

Which manual does it say? Any manual I've read last 20 years says quite opposite: never stop journaling unless you want to get your system in troubles.
It seems that you should not bother on the subject at all: during the database restore it can't be involved in any users' activity, so there would not exist any journal record on its change.