Connecting filter queries is slower than not connecting

[musiciansLyf]

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

[pawan (Pawan Rawal)]

@musiciansLyf

I want to know whether ‘@ filter’ is based on the root query ‘func’ for filtering or concurrent filtering and then taking the intersection?

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?

[musiciansLyf]

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

[pawan (Pawan Rawal)]

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

[musiciansLyf]

@pawan

census setup

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

[pawan (Pawan Rawal)]

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

[musiciansLyf]

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