Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ScanAllByLabelPropertyRange does not work with < and > operators #1954

Open
Josipmrden opened this issue Apr 22, 2024 · 0 comments · May be fixed by #2055
Open

ScanAllByLabelPropertyRange does not work with < and > operators #1954

Josipmrden opened this issue Apr 22, 2024 · 0 comments · May be fixed by #2055
Assignees
Labels
bug bug Effort - Low Effort - Low Frequency - Daily Frequency - Daily Priority - Later Priority - Later Reach - Some Reach - Some Severity - S2 Severity - S2
Milestone

Comments

@Josipmrden
Copy link
Contributor

Memgraph version
v2.16

Environment
Docker

Describe the bug
Although ScanAllByLabelPropertyRange operator is used in the query, it does not capture both lower and upper bound of the query.

To Reproduce
Steps to reproduce the behavior:

  1. CREATE INDEX ON :Node;
  2. CREATE INDEX ON :Node(id);
  3. FOREACH (i in range(1, 1000000) | CREATE (:Node {id: i}));
  4. PROFILE MATCH (n:Node) WHERE n.id > 1000 and n.id < 2000 RETURN sum(n.id);

Expected behavior
ScanAllByLabelPropertyRange operator should be applied with much smaller amount of rows.

Details
The details are in the index_lookup.hpp and preprocess.cpp
void Filters::AnalyzeAndStoreFilter(Expression *expr, const SymbolTable &symbol_table) function does not have the capability of generating a PropertyFilter of Type::Range, and that's why only upper or lower bound is written inside a property filter.

In the index_lookup.hpp, that filter is consumed and a ScanAllByLabelPropertyRange is applied, but with the maximal upper or lower bound, because we have applied only one filter to form an index. Furthermore, the second filter operation will be left out and virtual calls will be spent on unnecessary verification.

Possible solutions:

  1. Make processing of filters more effective -> this is a bit harder because the function SplitExpressionOnAnd is splitting those filters, but a post filter rewriter can do the job
  2. Make a rewriter on the operator level like we do with index lookup
@Josipmrden Josipmrden added bug bug Severity - S2 Severity - S2 Frequency - Daily Frequency - Daily Reach - Some Reach - Some labels Apr 22, 2024
@Josipmrden Josipmrden added this to the mg-v2.17.0 milestone Apr 22, 2024
@Josipmrden Josipmrden added the Effort - Low Effort - Low label Apr 22, 2024
@hal-eisen-MG hal-eisen-MG added the Priority - Later Priority - Later label Apr 28, 2024
@Josipmrden Josipmrden modified the milestones: mg-v2.17.0, mg-v2.18.0 May 20, 2024
@Ignition Ignition assigned Ignition and andrejtonev and unassigned Ignition May 23, 2024
@Ignition Ignition linked a pull request May 23, 2024 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug bug Effort - Low Effort - Low Frequency - Daily Frequency - Daily Priority - Later Priority - Later Reach - Some Reach - Some Severity - S2 Severity - S2
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants