Parallel Computing and inserting edge

There are two parts in my query. The main function is showed in the following picture. For each “substation” node, I use the node ID attribute as input and then call function “insertTopo”. The function “insertTopo” is about doing some computation and inserting some nodes and edges. It takes about 40ms to run insertTopo(“01115100000183”) and insertTopo(“01115100000182”) separately. But when I run the main function, it exceeds the query timeout threshold(120s). Is there any explaination for this problem? Thank you!微信图片_20200706130832

I’m guessing you have a lot of substations. The WHERE clause will filter all of them to return the two you are interested in, which will be relatively slow.

Instead you should use the to_vertex_set() function to retrieve the subset if that is what you want to do.

Try this: https://docs.tigergraph.com/dev/gsql-ref/querying/operators-functions-and-expressions#to_vertex-and-to_vertex_set

Actually there are only about 6000 substaion nodes and the select block “select_sub = select s from AllSubSet:s where s.ID == “01115100000183” or s.ID == “01115100000182”;” only takes about 10ms. I try analyzing the insertTopo subquery and I found the problem is related to the DML-sub level INSERT INTO statement.

If I remove the INSERT INTO statement, the three queries (insertTopo(“01115100000183”), insertTopo(“01115100000182”) and test()) can be run successfully within 100ms. If I add the INSERT INTO statement, the two queries (insertTopo(“01115100000183”) and insertTopo(“01115100000182”)) can be run successfully within 100ms, but test() will exceeds the query timeout threshold(120s).

Does anyone have any idea about the problem? Thank you!

Firstly, it should work. Not seeing the insertTopo code means there is at least a tiny chance something odd is going in there, but your testing seems sound to me.

If it is a bug in the product, then adjusting the code may fix it. For example use a post-accum in the code above (though I recognise it is probably test code and therefore may not be representative of the real situation).

If you’d rather not expose your code publicly on here, please get in touch privately (richardh@tigergraph.com) with the code/schema/version of product and I’ll open a support ticket and get the engineering team to see what is happening.