Connecting filter queries is slower than not connecting

Users Dgraph
1

To facilitate better answering of questions, if you have a question, please fill in the following questions. Otherwise, please delete the template.

I Want to Do

I want to add other filtering conditions based on the root query connection ‘@ filter’, but it is much slower than the unconnected one.
I want to know whether ‘@ filter’ is based on the root query ‘func’ for filtering or concurrent filtering and then taking the intersection?

What I Did

On the data volume of 1 million nodes, the connection ‘@ filter’ query takes 51 ms, while the unconnected query only takes 2 ms.

Dgraph Metadata

image
image2064×1268 313 KB

image
image2300×1302 330 KB

dgraph version v20.11.0
2

The @filter is applied to the result of the root query. So this is how it works.

  1. Execute root function and get a list of nodes as the result.
  2. Pass the list above to all the filters and execute them concurrently.
  3. Get back results from all the filters and intersect them with the list obtained in step 1.

I have a hunch why this might be happening which we can try. How many nodes of type affId and open_id do you have?

3

Thank you for your trouble. There are 145091 affId type nodes and 783446 open_id type nodes.

image
image2690×562 236 KB
image
image2582×530 252 KB

4

Do you have open census setup with your Dgraph instance and could you help us with a trace of your query?

6

Sorry, I’m not sure what this configuration means. Can you explain it in detail

7

https://dgraph.io/docs/deploy/tracing/ tells you how to setup OpenCensus tracing

8

OK, this is the trace information of zpages, but I don’t know how to find the trace of the query.

image
image2074×1172 267 KB

9

I was looking for a trace of the log with Jaeger. Could you try out Jaeger as mentioned at https://dgraph.io/docs/deploy/tracing/#examining-traces-with-jaeger and see if you can find the query trace? You should set the --trace flag of Alpha to a high value temporarily (say 0.5) to be able to track the query that is slow.

10

I’m sorry, because I didn’t reply in time for some other things. I’ll try to build Jaeger in the future to check the query information, and I’ll synchronize you when there is progress.