And specifying those indices explicitly cut the db hits in half! I had read
your Performance Tuning article and had put that little nugget on the back
burner, not realizing how critical it could be!
On Saturday, March 5, 2016 at 4:13:23 PM UTC-6, Jesse Hemingway wrote:
>
> Wow, there are a lot
Wow, there are a lot of ways to crack this nut. Thanks again for the
thought-provoking options. For a moment, I thought I was getting the hang
of Cypher, there is obviously I've only scratched the surface.
In the meantime, I'm back to square 1 on the first query, as I realized my
final
If the limit a parameter you could in those cases generate the string for
the statement and replace the numeric value.
Or you could use WHERE size(rels) < {limit} but I would go for creating the
query string.
the second query was not academic (my suggestions usually are not :) but a
Thank you Michael,
This is great insight, and helps me better understand query structure. As I
need the limit to be a parameter, I think it is not possible to use path
length as the limiter. It also turns out not every post is categorized, so
I found this variation on your suggestion to be
Hi Jesse,
your first query has to aggregate over all the p's first to get the
cagetories (you never know if the last p is the same as a previous one in
the result set and has yet another category that you also have to collect
for the post)
yours query just takes the first 50 pairs of posts and
I'm pretty new to neo4j, and I'm working on optimizing my queries. For my
example, let's say we have a lot of 'Post' nodes that can grow in an
unbounded fashion. I'm using a linked-list to be able to scan back through
recent posts without consulting every node. This works, but my question has
