Firebird 5 - use ParallelWorkers setting from firebird.conf as default for all parallelised operations

[tonne1]

as discussed with Vlad:

Currently parallel backup or restore using gbak is fine. But parallel backup or restore using a service does not use the new setting in firebird.conf. Users would have to patch their connectivity libs to get parallel processing there too, since most libs lag years behind Firebird development.

The service manager should get the ParallelWorkers setting from the engine, which knows it from firebird.conf, and use that as default.
If some different value was needed when calling a service, one could still configure a service differently e.g. by setting isc_spb_res_parallel_workers, but the default should be taken from ParallelWorkers in firebird.conf.

The default legacy behaviour (no parallelisation) remains unchanged since the default for ParallelWorkers in firebird.conf is 1. If someone changes that setting, it would mean, use parallelisation whereever possible and these are the resources the box can provide. Conceptually similar to the connection pool setting ExtConnPoolSize, default 0, no connection pooling.

This way no one would have to patch their connectivity libs and would benefit from the new feature right now, out of the box, by just setting a number in firebird.conf. In the meantime maintainers could gradually update their libs to include the new switches.
This approach (use ParallelWorkers as default) could also be applied to any parallelisation, where that's not the case already.

This does not mean utilities like gbak which don't have access to firebird.conf, since there one can use cmd line switches.

[tomaszdubiel18]

Yeah. Backup and restore are one of the most basic operations and when I was testing this, I was also surprised that I needed to use additional switch, when I already set the default number of workers in firebird.conf.

[tonne1]

Vlad, you made my day! Thanks so much! Tested with Build 1145 on an 8-core Windows box with ParallelWorkers = 6 in firebird.conf, backup and also restore over service_mgr run almost 3 times as fast as before. Without having to change a single line of code. Beau-ti-ful.

[hvlad]

Thanks, glad you liked it :)