Hello, un_spoken@...!

Thursday, June 9, 2016, 1:50:59 PM, you wrote:

uycuFg> This application is reading data from PostgreSQL database
uycuFg> (stored in JSON), parses the data, inserts it to Firebird
uycuFg> database and then scans the inserted data and inserts some
uycuFg> additional information. (Proccess of scanning the data must be
uycuFg> separated from initial inserts).

we made some synthetic parallel insert test with FB 2.5 and 3.0,
results are different than yours.
There were 1mln records inserted in total, in 1-2-4-8-16-32 threads.

1. FB 2.5 CS - the more threads, the more performance degrades
2. FB 3.0 CS - the same as 2.5 CS
3. FB 3.0 SS - very little difference between inserting in 1 and 32
threads. So, this breaks myth that inserts (to one table) can be speed
up by splitting it to different threads
4. FB 2.5 SS - 32 threads are 3 times slower than 1 thread

uycuFg> 3.0 SS 4 THR - In my opinion behaved unstable. There were
uycuFg> lost connections to database and threads had to reconnect. At
uycuFg> first I thought it is a coincidence so I've repeated the test and it happened again.

seems that this is related to your application, how you deal with
connections and threads in it. Our tests had no any "unstability" even
at 32 threads.

--
Dmitry Kuzmenko, www.ib-aid.com