GVMd 8 SCAP update takes a looong time

GVM versions

gsa-v8.0.1
gvm-v8.0.1
openvas-scanner-v6.0.1
gvm-libs-v10.0.1

Environment

Ubuntu Linux 19.04
Kernel version 5.0.0.25

Installation method / source:
Built from source

All works fine, no problems. The only small alteration to build defaults I did was configuring gvm with cmake “-DBACKEND=POSTGRESQL” otherwise it defaults to sqlite3 from what I could understand in the CMakeLists.txt file

Then gvmd: Syncing SCAP takes a looong time. it is this process taking its while for like 10-15 mins and then postgres itself using a whole CPU core up for a few hours.

It eventually finishes and works like a charm.

Is this expected ?
Can I tune anything in Postgres may be so it happens quicker ?

Increasing RAM and number of cores did not help. It will use either 1 core fully or 2 cores 50% each.
I read up on Postgres, which it looks like default values are more than enough for anything

Check if you XSLT Transformation takes this time. More CPU does not help be course XSLTproc can only run single CPU. A NVME and faster CPU would help.

Yeah, there is a proper server storage that helps with super fast I/O, clearly not enough.

With regards to XSLT transform taking a long time, would this happen within PostGres ? Does not sound probable to me, unless you know something I don’t. Does that work like an external function supplied by gvm ?
How could I tell if that is the bottleneck ?

This has nothing to do with the database, it´s the transformation of the XML Files.Why is this so critical ? Normally this happens within the background over night …