@Raphael @vnium , sure I can elaborate further.
Running the original query takes 160475274744 ns. Modifying the query as suggested takes 147264831335 ns which is marginally better. I tested it again and it took 172891140041 ns, so a bit worse than the original query. Thats some variance which is to be expected i guess.
Just querying for the parameter “the original way”
query {
query(func: type(Parameter)) @filter(eq(Parameter.key, "someKey")) {
count(uid)
}
}
takes 59506088 ns, querying it the suggested way
query {
query(func: eq(Parameter.key, "someKey")) {
count(uid)
}
}
takes 1159657 ns. So yes, as expected this way of querying parameters is faster, but that does not make up for the remaining time spend for the full query.
What i meant by going one level further is the following. I just queried parameters and counted just the parameters which is super quick (less than a second). The next level would be aggregating the linked buckets, so
query {
var(func: eq(Parameter.key, "someKey")) {
Parameter.inBuckets {
buckets as uid
}
}
query(func: uid(buckets)) {
count(uid)
}
}
which takes 777101367 ns, still more than quick enough. The next level is aggregating the linked files of the buckets (original query) which is already stated above, taking critically longer.
Coming to a conclusion: ill for sure start writing queries the suggested way, but this does not help in this specific case. Yes its more performant, but it does not solve the described issue.
Maybe some context to my db. There are 313707 files, 2885203 buckets and 1189707 parameters. The relation can be seen in the schema snippet in the original post. The Parameter.key “someKey” relates to 2 parameters. Linked to those two parameters are 2483757 buckets. Linked to the buckets are 41505 files.