On Tue, May 11, 2021 at 11:54 AM, <hadoopmarc@...> wrote: https://docs.janusgraph.org/advanced-topics/bulk-loading/#optimizing-id-allocation Thanks for response Marc. Below is the method i am using

Hi Anjani, Please show the properties file you use to open janusgraph. I assume you also saw the other recommendations in

Hi All, I am creating vertex and edges in bulk and getting below error while creating edge. Below is the exception log:I tired increasing value of "ids.block-size" but still no luck, even set to 1B

Hi Vinayak, Actually, query 4 was easier to rework. It could read somewhat like: g.V().has('property1', 'vertex1').as('v1').outE().has('property1', 'edge1').limit(100).as('e').inV().has('property1',

Hi Marc, Thank you for your reply. I will try to report this issue on janusgraph repository. Regarding the work around you suggested, if possible please share the updated query with work around for

Hi Vinayak, If you would bother to demonstrate this behavior with a reproducible, generated graph, you can report it as an issue on github. For now, you can only look for workarounds: - combine the

Hi Marc, This query takes 18 sec to run by changing as to aggregate and select to project. But still, 99% of the time is taken to compute union. There is no memory issue, it already set to

Hi Vinayak, Your last remark explains it well: it seems that in JanusGraph a union of multiple clauses can take much longer than the sum of the individual clauses. There are still two things that we

Hi Marc, That works as expected. Union also works as expected as in Query1 but when I add limit to all edge the performance degrades. Thanks

Hi Vinayak, What happens with a single clause, so without the union: g.V().has('property1', 'vertex3').outE().has('property1', 'edge3').inV().has('property1',

Hi Marc, Yes, all the index are made available and no warning is thrown while executing the query. I tried debugging using profile step. 99% of time is taken by the union query. Thanks &

Hi Vinayak, To be sure: we are dealing here with a large graph, so all V().has('property1', 'vertex...') steps do hit the index (no index log warnings)? For one, it would be interesting to see the

Hi Marc, Tried the approach you suggested. There is some improvement. Earlier it took 2 mins, now it's taking 1min 50sec. Is there any other way to optimize this further may to ms or seconds?? Thank

Hi Vinayak, My answer already contains a concrete suggestion. Replace all union subclauses starting with outE with the alternate form that has a local(................limit1)) construct, as

Hi Marc, Thank you for your reply. I understand the queries are big, so there is a problem viewing them. Actually I am not interested in either of v1 or v2. I want to apply limit on edges, and don't

Hi Vinayak, Can you please try and format your code in a consistent way to ease the reading (even if the editor in this forum is not really helpful in this)? After manual reformatting, Query 1 and the

Hi Sai, The blog you mentioned is a bit outdated and is for spark-1.x. To get an idea of what changes are needed to get OLAP running with spark-2.x, you can take a look

Hi All, g.inject(1).union(V().has('property1', 'vertex1').as('v1').union(outE().has('property1', 'edge1').as('e').inV().has('property1', 'vertex1'),outE().has('property1',

Hi Marc, I got this when querying using OLTP: gremlin> g.V(1469152598528) ==>v[1469152598528] gremlin> g.V(1469152598528).elementMap() ==>[id:1469152598528,label:vertex] I am also trying to run spark

Hi Sai, What happens in createTraversal()? What do you get with g.V(1469152598528).elementMap() if you open the graph for OLTP queries? Best wishes, Marc