Compare query performance

App Development
1

How can I compare the performance of my queries? Is there a tool that shows the number of nodes touched or the query time?

Also, a general question:

Let’s say I am querying for a “Resource” using a name, which is a UID:

	query := fmt.Sprintf(`
	{
		all(func: eq(name, "name")) {
			resource as uid
		}
	}

I have some other fields as well in the Resource schema, such as “Class.”

Resources can be classified into different types using the “Class” field. Is it better to query just with the name as above or to do something like this:

{
  all(func: type(Resource)) @filter(eq(class, "class1") AND eq(name, name)) {
    resource as uid
  }
}

Which query is more efficient in a graph with approximately 300,000-500,000 resource nodes?
And yes the “name” field is indexed

name: string @index(hash) .

Would appreciate any help!
TIA!

2

IMHO, try to usually avoid type as a root query in most all cases.

Try to put your most uniquely indexed predicate as the root.

In your example, I would assume that name is probably your most unique predicate. You already said it was indexed.

What your goal should be for performance is to decrease the universe of nodes as early as possible in the root.

I’m assuming you use class more like a category of Resources. If class was more unique then exchange it to your root.

You still will need the type filter in the filters in case you have other types that might also use the same plane predicate.

I actually recommend to use the type dotted predicates for best performance and scalability. (It helps when rebalancing shards to have smaller shard sizes)

So instead of name I would recommend to use Resource.name, but this only works if you don’t expect to be able to query all names of different types together.

{
  all(func: eq(name, "your-name")) @filter(eq(class, "class1") AND type(Resource)) {
    resource as uid
  }
}
1 Like
3

Yes, “name” in my graph is a unique predicate. It’s an UID so I won’t have any other node with the same name.

Using “Resource.name” makes sense. Will do that!
So when querying I can just use the name field and skip the “class” because graph should be able to find the node with the given name directly. Or do I move the “class” filter before the name filter?

1 Like