Discussion Forum

Performance of match query is extremely slow on nearly empty graph

I have a graph with some rules and entities, of which one entity type is mostly isolated (not part of any relations but does act a role).

I’ve defined this entity type, user, below:

containment sub relation,
  relates container,
  relates containee;

uuid sub attribute, value string;
last-seen sub attribute, value datetime;

user sub entity,
  has uuid,
  has last-seen,
  plays containee;

The attributes are only owned by user. I currently have 5 user instances in my graph that I put in for testing, and when I run match queries I get severely degraded performance.

For example, consider the following query:

match $u isa user, has uuid "test"; get; offset 0; limit 1;

This query clocks in at ~100 calls over a 30 second period, which IMO is extremely slow considering how often we might want to get a very specific user from the database. More complex queries that involve querying the user with relations are exponentially slower.

However, it takes less than a second to complete 2000 insert queries (without match clauses). This leads me to believe there is some aspect of my entity definition or syntax that is resulting in very slow match queries.

I’m wondering where to even begin looking (or if this is actually expected speed)?

1 Like

Hi @pshah123, thanks for posting.

This sounds far too slow. I’m confused by this:

This query clocks in at ~100 calls over a 30 second period

Are you doing this query match $u isa user, has uuid "test"; get; offset 0; limit 1; 100 times and it takes 30 seconds? Please elaborate on that.

With only 5 user instances each having one uuid each I would expect this to be very fast.

Things you can try:

  • re-use the same transaction for multiple queries (if you aren’t already). Opening a transaction incurs some time cost, though this shouldn’t be particularly high and therefore I think it isn’t your issue. If you are using a whole session per query that could be the cause.
  • try setting uuid to be a key as follows:
user sub entity,
  has uuid @key,
  ...

How many other entities/relations/attributes are in the DB? This shouldn’t make a difference of course, but good to know.