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

add rule and update op_var_len_expand #485

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

peace-dove
Copy link

  1. add rule: push edge filter into op_var_len_expand
  2. update: non-recursive version of DFS in op_var_len_expand, searching edge with pruning

@CLAassistant
Copy link

CLAassistant commented Apr 24, 2024

CLA assistant check
All committers have signed the CLA.

@peace-dove peace-dove force-pushed the dev_op_var_len_expand branch from 0b11481 to 3b17978 Compare April 24, 2024 13:07
@peace-dove peace-dove closed this Apr 24, 2024
@peace-dove peace-dove reopened this Apr 24, 2024
@peace-dove peace-dove force-pushed the dev_op_var_len_expand branch from 3b17978 to 6a986b7 Compare April 24, 2024 13:29
@peace-dove peace-dove force-pushed the dev_op_var_len_expand branch from 5f5707c to 4b4b9ca Compare April 26, 2024 15:59
@peace-dove
Copy link
Author

Please reapprove the workflow, thanks. @qishipengqsp

@peace-dove
Copy link
Author

Return to optimized version 1, where all edges in the path need to be scanned during the expansion.
To some extent, this version is more readable, and it is possible to avoid the problem of NULL pointers.

@qishipengqsp qishipengqsp requested a review from spasserby May 8, 2024 07:15
@peace-dove
Copy link
Author

It is ready for review. @qishipengqsp

Copy link
Collaborator

@qishipengqsp qishipengqsp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add more unit test cases to check the functionality and the OPT rule.

Generally LGTM to me in the discussed specific case. Can be more pervasive with more general scenarios as input.

OPT checks in this PR in the future:

  • Hard encoding of the function names to check the rule
  • The design of predicates for scalability consideration
  • Double-check the correctness after making it more pervasive

}
}

bool _FindEdgeFilter(OpBase *root, OpFilter *&op_filter, VarLenExpand *&op_varlenexpand) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we check the pattern isAsc() and isDesc() ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now, all predicates for op_var_len_expand allowed by cypher can be optimized by this rule, so maybe there is no need to check here now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more test cases for this rule are expected

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find some tests in tugraph-db/test/resource/cases/finbench/cypher/. I did not find test cases for other RBO rules, I dare not add test files at random.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice try to move the code to source file

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this can speed up compilation.
Should I keep it in the source file or keep it consistent with other files and move it to the header file?

src/cypher/execution_plan/ops/op_var_len_expand.h Outdated Show resolved Hide resolved
if (tmp_filter->GetAeLeft().op.type == cypher::ArithOpNode::AR_OP_FUNC) {
std::string func_name = tmp_filter->GetAeLeft().op.func_name;
std::transform(func_name.begin(), func_name.end(), func_name.begin(), ::tolower);
if (func_name == "isasc") {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hard coding of func_name is not a good idea.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean to use BuiltinFunction::FUNC to determine which function?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The applying of the edge filter is relevant to the language expression of RPQ.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but it's still not clear whether there is any predicate on the path that can be optimized in this way.

addPredicate(std::move(p));
} else if (func_name == "isdesc") {
auto p = std::make_unique<IsDescPredicate>();
addPredicate(std::move(p));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The move function is redundant to the one inside addPredicate

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that without this std::move, the compilation will fail.

@qishipengqsp
Copy link
Collaborator

Please reapprove the workflow, thanks. @qishipengqsp

Reviewed. Will discuss this PR offline

@peace-dove peace-dove force-pushed the dev_op_var_len_expand branch from fcab98b to b49f88a Compare November 29, 2024 10:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants