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

Feature/index scan limit push down #2823

Conversation

Shylock-Hg
Copy link
Contributor

Require #2796

Sub job of #2602

@Shylock-Hg Shylock-Hg requested review from a team September 8, 2021 08:33
@bright-starry-sky
Copy link
Contributor

please resolve the conflicts.

@Shylock-Hg
Copy link
Contributor Author

please resolve the conflicts.

Done.

@Shylock-Hg Shylock-Hg added the ready-for-testing PR: ready for the CI test label Sep 15, 2021
@bright-starry-sky
Copy link
Contributor

I didn't find the keyword LIMIT in lookup_sentence, did you solve it via other way?

@Shylock-Hg
Copy link
Contributor Author

I didn't find the keyword LIMIT in lookup_sentence, did you solve it via other way?

In the compound sentence lookup .. | limit 3, 5

@bright-starry-sky
Copy link
Contributor

I didn't find the keyword LIMIT in lookup_sentence, did you solve it via other way?

In the compound sentence lookup .. | limit 3, 5

I see. our ideas seem to diverge,let me explain what I think.I'm not sure what I think is right. It's just a discussion.
for example :
part1 ---> 10 rows;
part2 ---> 10 rows;

  • lookup tag ... limit 5 ---> The number of rows returned should be 5 + 5 == 10 (part1 = 5 rows, part2 = 5 rows)
  • lookup tag ... | limit 5 ---> The number of rows returned should be 5 (part1 = 10 rows, part2 = 10 rows, need to truncate it to 5 rows at the graph layer)
  • lookup tag ... limit 5 | limit 6 ---> The number of rows returned should be 5 + 5 == 10 (part1 = 5 rows, part2 = 5 rows. need to truncate it to 6 rows at the graph layer)

@Sophie-Xie Sophie-Xie requested review from CPWstatic and removed request for a team September 16, 2021 05:06
@Shylock-Hg
Copy link
Contributor Author

I didn't find the keyword LIMIT in lookup_sentence, did you solve it via other way?

In the compound sentence lookup .. | limit 3, 5

I see. our ideas seem to diverge,let me explain what I think.I'm not sure what I think is right. It's just a discussion.
for example :
part1 ---> 10 rows;
part2 ---> 10 rows;

  • lookup tag ... limit 5 ---> The number of rows returned should be 5 + 5 == 10 (part1 = 5 rows, part2 = 5 rows)
  • lookup tag ... | limit 5 ---> The number of rows returned should be 5 (part1 = 10 rows, part2 = 10 rows, need to truncate it to 5 rows at the graph layer)
  • lookup tag ... limit 5 | limit 6 ---> The number of rows returned should be 5 + 5 == 10 (part1 = 5 rows, part2 = 5 rows. need to truncate it to 6 rows at the graph layer)

Fixed.

critical27
critical27 previously approved these changes Sep 18, 2021
@yixinglu
Copy link
Contributor

@CPWstatic @yixinglu, PTAL.

@critical27 @bright-starry-sky

I don't agree with the changes about the Plan Node kind, this new definition is quite ugly. I prefer to meet the needs by enhancing the flexibility of pattern, rather than by modifying the way plan node's kind is defined.

@Shylock-Hg
Copy link
Contributor Author

@CPWstatic @yixinglu, PTAL.

@critical27 @bright-starry-sky

I don't agree with the changes about the Plan Node kind, this new definition is quite ugly. I prefer to meet the needs by enhancing the flexibility of pattern, rather than by modifying the way plan node's kind is defined.

How to enhance the pattern?

@Sophie-Xie Sophie-Xie added this to the v2.6.0 milestone Sep 22, 2021
@yixinglu
Copy link
Contributor

@CPWstatic @yixinglu, PTAL.

@critical27 @bright-starry-sky
I don't agree with the changes about the Plan Node kind, this new definition is quite ugly. I prefer to meet the needs by enhancing the flexibility of pattern, rather than by modifying the way plan node's kind is defined.

How to enhance the pattern?

Try one rule to match multiple patterns

static Pattern pattern = Pattern::create(
graph::PlanNode::Kind::kLimit,
{Pattern::create(graph::PlanNode::Kind::kProject,
{Pattern::create(graph::PlanNode::Kind::kIndexScan, {}, true)})});
Copy link
Contributor

Choose a reason for hiding this comment

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

here should not be one opt rule, but should be split into two rules: limit <-> project, limit -> indexscan

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why need limit->indexscan?

Copy link
Contributor

Choose a reason for hiding this comment

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

Push limit down indexscan

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The sentence only generate limit->project->indexscan plan

Copy link
Contributor

Choose a reason for hiding this comment

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

You should consider the optimization rules from the perspective of the optimizer, not just for this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't need to match the nonexistent pattern.

@Sophie-Xie Sophie-Xie removed the request for review from CPWstatic September 23, 2021 07:04
@Shylock-Hg
Copy link
Contributor Author

Shylock-Hg commented Sep 23, 2021

@CPWstatic @yixinglu, PTAL.

@critical27 @bright-starry-sky
I don't agree with the changes about the Plan Node kind, this new definition is quite ugly. I prefer to meet the needs by enhancing the flexibility of pattern, rather than by modifying the way plan node's kind is defined.

How to enhance the pattern?

Try one rule to match multiple patterns

I think it's ok. We could refactor when get better way in future.

@Shylock-Hg Shylock-Hg added the doc affected PR: improvements or additions to documentation label Sep 26, 2021
@bright-starry-sky
Copy link
Contributor

What's new advances ? @Shylock-Hg @yixinglu .
If some differences require further discussion. would be better to split the current PR into two?

@yixinglu
Copy link
Contributor

yixinglu commented Sep 27, 2021

What's new advances ? @Shylock-Hg @yixinglu .
If some differences require further discussion. would be better to split the current PR into two?

I don’t accept refactoring in the future. If don’t want to optimize the pattern this time, then implement a few more similar optimization rules.

@Shylock-Hg
Copy link
Contributor Author

Shylock-Hg commented Sep 27, 2021

What's new advances ? @Shylock-Hg @yixinglu .
If some differences require further discussion. would be better to split the current PR into two?

I don’t accept refactoring in the future. If don’t want to optimize the pattern this time, then implement a few more similar optimization rules.

In fact, I'm not sure about refactoring. Match variants at once is reasonable demand in this optimizer. Write multiple almost similar rules is not well.

@codecov-commenter
Copy link

Codecov Report

Merging #2823 (4b995d8) into master (dddf54e) will decrease coverage by 0.75%.
The diff coverage is 61.94%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2823      +/-   ##
==========================================
- Coverage   85.47%   84.71%   -0.76%     
==========================================
  Files        1229     1232       +3     
  Lines      110375   110924     +549     
==========================================
- Hits        94341    93974     -367     
- Misses      16034    16950     +916     
Impacted Files Coverage Δ
src/clients/meta/MetaClient.h 92.30% <ø> (ø)
src/clients/storage/GraphStorageClient.h 100.00% <ø> (ø)
src/common/utils/NebulaKeyUtils.cpp 89.03% <0.00%> (-4.89%) ⬇️
src/common/utils/NebulaKeyUtils.h 78.02% <ø> (ø)
src/graph/executor/query/IndexScanExecutor.cpp 88.88% <ø> (ø)
src/graph/optimizer/OptRule.h 100.00% <ø> (ø)
src/graph/planner/plan/Admin.cpp 54.23% <0.00%> (-2.40%) ⬇️
src/graph/planner/plan/Scan.h 74.13% <0.00%> (-25.87%) ⬇️
src/graph/service/PermissionCheck.cpp 83.72% <ø> (+2.32%) ⬆️
src/kvstore/KVEngine.h 100.00% <ø> (ø)
... and 137 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 073fb37...4b995d8. Read the comment docs.

@Sophie-Xie Sophie-Xie added the need to discuss Solution: issue or PR without a clear conclusion on whether to handle it label Sep 27, 2021
@Shylock-Hg Shylock-Hg linked an issue Sep 28, 2021 that may be closed by this pull request
@Sophie-Xie Sophie-Xie removed the need to discuss Solution: issue or PR without a clear conclusion on whether to handle it label Sep 28, 2021
@Shylock-Hg
Copy link
Contributor Author

Reopen in #2966

@Shylock-Hg Shylock-Hg closed this Sep 28, 2021
@Shylock-Hg Shylock-Hg deleted the feature/index-scan-limit-push-down branch February 9, 2022 07:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc affected PR: improvements or additions to documentation ready-for-testing PR: ready for the CI test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature] index scan limit push down
7 participants