Connecting filter queries is slower than not connecting

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

dgraph version v20.11.0

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?

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

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

Sorry, I’m not sure what this configuration means. Can you explain it in detail tells you how to setup OpenCensus tracing

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

I was looking for a trace of the log with Jaeger. Could you try out Jaeger as mentioned at 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.

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.