Skip to content

performance issues of deep filters #63

@jexp

Description

@jexp

deep filters don't use the indexes but do label scan + filter

i.e. currently we generate ALL(expr IN [(start)-->(next:Next) | next.name = $foo] WHERE expr)

and nested variants of this for each level of nested filters

  • we also do NONE/SINGLE/SOME(expr ...)

which we had to generate because:

  1. we need the names to express arbitrary predicates and to drill down deeper
  2. I didn't think on how to represent ALL except of list of all expression results has to be true

but that leads to indexes not being used

we can change this to: size([(start)-->(next:Next) WHERE next.name = $foo | true]) = 0 where the = 0 depends on the below

  • ANY(some): size > 1
  • SINGLE: size = 1
  • NONE: size = 0
  • ALL: size = 0 with inverted condition

this works a bit for single level but for deeper nesting it breaks the planner

one idea is to skip intermediate levels if there are no additional filters

e.g. size([(start)-->(middle)-->(next:Next) WHERE next.name = $foo | true]) = 0

originally we would generate:

size([(start)-->(middle) WHERE size([(middle)-->(next:Next) WHERE next.name = $foo | true]) = 0 | true]) = 0

in 4.0 we can generate existential subqueries to help with that

WHERE exists { MATCH ... WHERE ... } I think will be the syntax.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions