Thanks Steve
Well, the full story is too complex - but point was - whatever blackbox does - it last 0.5 to 2secs per 1 processed record (maybe I was wrong but I thought the reason why it takes the time how much it needs to actually do the task -CPU/IO/memory whatever is not that important....) - so I really don't see difference between: call web service, insert row in the table (takes 3 secs) and sleep 3 seconds - insert result in the table...
if we do above task for two things sequential - it will last 6 secs...but if we do it "concurentelly" - it should last 3 secs... (in theory :) )
I was guessed somewhere is lock - but wasn't clear where/why when there are no updates - just inserts...
But I haven't know that during INSERT is done row lock on refferenced tables as well - from FK columns...
So I guess now it is cause of the problem...
We will see how it goes with insert into unlogged tables with no FK...
Many thanks,
Misa
2013/3/12 Steve Crawford <scrawford@xxxxxxxxxxxxxxxxxxxx>
On 03/11/2013 08:55 PM, Misa Simic wrote:
Hi all,do_the_math_for_record(record_id)...<snip>...
We have one table with list of "records for processing"...
We loop trough that table and call one long runing function:
but - if replace do_the_math_and_save_results with pg_sleep(1); To simulate long running function so processing each row - last 1 sec...
Sequential processing last as expected 300 seconds!
Concurrent processing last faster with higher number of concurrent connections - about 30 seconds with 30 connections! (much faster - and expected...)
however, if we return our: do_the_math_and_save_results - we can't get better results in concurrent processing...
Sleep will not have any significant impact on CPU, memory or disk use and thus is not a simulation of actual processing.
All you have really shown us so far is a black box. Please provide an overview of your schemas and the type of processing you are attempting on them.
Cheers,
Steve
