Is query performance degrade by "joins"?

Users Dgraph
1

Hi every one!

My schema is:

organization.id: string @index(hash) @upsert @count .
element.id: string @index(hash) @count .
owner: uid @count @reverse .

Where organization can owns several elements.

I have several queries which return same results but there is really big different between response time. Why?

Takes 1s.

{
  var(func: eq(organization.id,"demo"), first: 1) {
    OWNED as ~owner
  }
  
  ELM as var(func: has(element.id))

  result(func: uid(OWNED)) @filter(uid(ELM)) {
     count: count(uid)
   }
}

This one takes 23s.

{
  var(func: eq(organization.id,"demo"), first: 1) {
    OWNS as ~owner
  }

  result(func: uid(OWNED)) @filter(has(element.id)) {
     count: count(uid)
   }
}

And this one takes 6s

{
  var(func: eq(organization.id,"demo"), first: 1) {
    OWNED as ~owner @filter(has(element.id))
  }

  result(func: uid(OWNED)) {
     count: count(uid)
   }
}
2

It would be interesting that you could test this in a place that everyone has access to. Like for example https://play.dgraph.io/. This Query below can be executed there and took 37ms.

If you can play in the play dgraph it’s easier for us to say something about it.

{
 var(func: eq(name@., "Western"), first: 1){
    OWNS as  ~genre { name@.}
  }

result(func: uid(OWNS)) @filter(has(initial_release_date)) {
     count: count(uid)
   }
}

Cheers.

3

You can see big difference between queries response on play.draph.io, too.

Try this:

{
  var(func: eq(name@., "Western"), first: 1) {
    OWNED as ~genre
  }
  
  ELM as var(func: has(initial_release_date))

  result(func: uid(OWNED)) @filter(uid(ELM)) {
     count: count(uid)
   }
}

Average response time:
1s,3s,5s

{
  var(func: eq(name@., "Western"), first: 1) {
    OWNED as ~genre @filter(has(initial_release_date))
  }

  result(func: uid(OWNED)) {
     count: count(uid)
   }
}

Average response time:
19ms,19ms,19ms

{
  var(func: eq(name@., "Western"), first: 1) {
    OWNS as ~genre
  }

  result(func: uid(OWNS)) @filter(has(initial_release_date)) {
     count: count(uid)
   }
}

Average response time:
20ms,20ms,19ms

4

These results are not so bad. Only the first seems significant. But here it averaged 150ms.

BTW, the Team started working to improve the LRU. Soon this may bring even better results than today.

Cheers.

5

No, no. I don’t think that dGraph is slow.
I’ve just wonder if there is some pattern how to build query.
You can see, that there is three different form of one query which have significant difference in response time.

6

Okay, maybe this is because this query has 3 queries blocks that depend on each other and are running concurrently. The ELM var is doing a wide query so does the other block wait for it, in my view.

The second and third examples are better because you are applying “Has” to filters within the correct context.