Open tucnak opened 5 years ago
I've also tested cockroach, and got the following result:
2019/02/12 04:20:15 n = 10
2019/02/12 04:20:15
2019/02/12 04:20:15 [find n critiques] started
2019/02/12 04:20:15 found 10
2019/02/12 04:20:15 elapsed: 28.113888ms
2019/02/12 04:20:15
2019/02/12 04:20:15 [find n knols + depth=0] started
2019/02/12 04:20:16 found 8
listening...
In the case (a) cockroach is 2x faster than postgres, but later it fails to load (b) completely. I suspect that cockroach driver's implementation is probably based off postgres driver, and could be lagging behind.
As mentioned in Slack discussion, this is due to a bug in query optimizer - it won't let SQL to run a full optimization pass for recursive queries.
Fixing the issue allows recursive queries to be optimized, but a set of output SQL queries turns out to be slower then the scan from Cayley side.
So this will require more work to implement properly - need to add a few more optimizers to SQL.
Postgres driver performs badly on certain simple recursive queries. Herein are two Gizmo queries (a trivial select by-type and a recursive walk over the tree) over n=8258 nodes.
Toy dataset (n-quads, 2mb compress) used in this example: knols.nq.zip
Received results:
Expected results:
dennwc [12:45 AM] Is it for Postgres? It looks weird.
linksto -> fixed
should be optimized away Thoselinksto(fixed)
in the tree mean that it does the lookup+scan manually, instead of usingWHERE
.Output of
cayley version
or commit hash: acf0ab2a9511Environment details:
Backend database:
postgres 10.5
@dennwc